Introduction : Construire l'Expérience sur un Fondement de Confiance

Les appareils OpenHarmony sont omniprésents dans la vie quotidienne des utilisateurs. Ils enregistrent des trajectoires de conduite, surveillent des données de santé et capturent des images familiales. Une faille de sécurité peut compromettre non seulement les données, mais aussi la confiance placée dans l'ensemble de l'écosystème.

Cependant, de nombreuses applications Flutter + OH présentent des risques importants, notamment le stockage en clair d'informations sensibles, l'absence de vérification de signature pour les mises à jour à chaud, l'accès non autorisé lors des appels distribués et des demandes de permissions excessives.

Cet article propose des pratiques de développement sécurisé concrètes, auditables et vérifiables, basées sur les normes de sécurité applicatives OpenHarmony et les réglementations en vigueur, couvrant le stockage, la communication, les permissions, les mises à jour et la protection de la vie privée.

1. Principes de Conception Sécurisée

Concept fondamental : La sécurité doit être l'état par défaut de l'application.

2. Stockage des Données Sensibles : HUKS et Bac à Sable Sécurisé

2.1 Interdiction du Stockage en Clair

Exemple incorrect :

// Stockage d'un jeton dans SharedPreferences (en clair !)
var prefs = await SharedPreferences.getInstance();
prefs.setString('auth_token', userToken);

Approche correcte : Utiliser le chiffrement via HUKS OpenHarmony.

// Appel à la couche native de chiffrement via un plugin
final encryptedData = await HUKSSecurityPlugin.encrypt(
  keyIdentifier: 'auth_token_key',
  plainText: userToken,
);

// Stockage du texte chiffré
await EncryptedLocalStorage.save('secured_token', encryptedData);

Avantages de HUKS : les clés sont protégées par un environnement d'exécution de confiance (TEE), impossibles à extraire même sur un appareil avec accès root, et supportent les algorithmes nationaux SM4/SM2.

2.2 Règles de Localisation du Stockage

Interdiction formelle d'écrire des données sur un stockage externe ou dans des répertoires partagés globaux.

3. Sécurité de la Communication Distribuée : Lier l'Inter-Appareil

3.1 Authentification de l'Identité de l'Appareil

Avant d'invoquer une capacité (par exemple, la caméra d'un véhicule), il est impératif de vérifier que l'appareil distant appartient bien à l'utilisateur :

Future<bool> isDeviceAuthorized(String remoteDeviceId) async {
  final localUserId = await AccountManager.fetchLocalUserId();
  final remoteUserId = await DeviceManager.fetchDeviceUserId(remoteDeviceId);
  return localUserId == remoteUserId; // Vérification du même compte Huawei
}

3.2 Contrôle d'Accès aux Capacités

Même sur un appareil de confiance, une vérification des permissions spécifiques est nécessaire :

// Vérifier la permission avant d'accéder à la caméra du véhicule
if (await PermissionVerifier.granted(
  deviceId: vehicleId,
  permissionName: 'ohos.permission.CAMERA',
)) {
  DistributedCapacities.invoke(vehicleId, 'activateCamera');
} else {
  showPermissionRequestDialog(); // Guidage de l'utilisateur vers l'autorisation
}

Note cruciale : Dans OpenHarmony, l'appareil contrôlé doit également donner son consentement explicite. La permission du contrôleur seule est insuffisante.

4. Gestion des Permissions : Demande Dynamique et Éducation de l'Utilisateur

4.1 Demande au Moment du Besoin

Anti-modèle : Demander toutes les permissions au lancement de l'application.

Flux correct :

1. L'utilisateur clique sur "Scanner un QR code".
2. Le système vérifie si la permission de la caméra est déjà accordée.
3. Si non, afficher une explication contextuelle : "L'accès à la caméra est nécessaire pour scanner le code."
4. Invoquer la demande de permission correspondante.

4.2 Offrir un Point de Contrôle des Permissions

Intégrer dans les paramètres de l'application une section "Confidentialité" permettant :

• Afficher la liste des permissions actuellement accordées.
• Fournir un bouton pour révoquer les permissions.
• Afficher un journal d'utilisation (ex : "Position utilisée hier à 14:30").

Exigence réglementaire : Conformément aux lois sur la protection des données personnelles, les utilisateurs ont le droit de retirer leur consentement à tout moment.

5. Mises à Jour à Chaud et Sécurité du Code

5.1 Signature Obligatoire des Mises à Jour

Future<void> applyHotUpdate(String downloadUrl) async {
  final updatePackage = await HttpClient.download(downloadUrl);
  final packageSignature = updatePackage.headers['x-integrity-signature']!;

  final isValid = SignatureVerifier.validate(
    payload: updatePackage.body,
    signature: packageSignature,
    trustedPublicKey: embeddedAppKey,
  );

  if (!isValid) {
    throw SecurityViolation('Le package de mise à jour a été altéré !');
  }
  HotUpdateLoader.safeDeploy(updatePackage.body);
}

5.2 Exécution de Code Dynamique Interdite

• Interdire l'utilisation d'instructions d'évaluation dynamique ou de réflexion avancée.
• Interdire le téléchargement et l'exécution de scripts depuis le réseau.
• Autoriser uniquement le chargement de packages pré-signés et pré-validés.

Note pour la validation : Les mécanismes de mise à jour à chaud doivent être inclus dans le rapport d'évaluation de sécurité lors de la soumission aux magasins d'applications.

6. Conformité à la Protection de la Vie Privée

6.1 Politique de Confidentialité Transparente

Lors du premier lancement, présenter un résumé concis de la politique, précisant clairement :

• Les données collectées (ex : "uniquement les pas de marche, pas de localisation").
• Leur utilisation (ex : "pour générer un rapport hebdomadaire, non partagé").
• Leur lieu de stockage (ex : "les données restent sur votre montre connectée").

6.2 Minimisation de la Collecte des Données

Risque légal : La collecte de données personnelles non essentielles peut entraîner des amendes significatives.

7. Checklist de Sécurité Avant Mise en Production

• ✓ Tous les champs sensibles stockés localement sont-ils chiffrés ?
• ✓ Les appels distribués vérifient-ils l'identité de l'appareil ?
• ✓ Les permissions sont-elles demandées à la demande et offrent-elles un mécanisme de révocation ?
• ✓ Les packages de mise à jour à chaud sont-ils signés et vérifiés ?
• ✓ La politique de confidentialité est-elle claire et accessible ?
• ✓ L'application a-t-elle passé l'analyse de sécurité avec un outil de développement approprié (sans vulnérabilités critiques) ?
• ✓ Les journaux de débogage sont-ils désactivés dans la version de production ?

8. Outils et Ressources

Outils officiels :

• Scanner de Sécurité de l'IDE : Détection automatique des risques liés aux permissions, au stockage et à la communication.
• Utilitaire de débogage HUKS : Vérification des processus de génération de clés et de chiffrement/déchiffrement.
• Tableau de bord de la confidentialité (au niveau système) : Permet aux utilisateurs de consulter l'utilisation des données par chaque application.

Plugins recommandés pour Flutter :

• oh_secure_storage : Intègre HUKS, la gestion des permissions et le stockage sécurisé.
• privacy_consent_manager : Fournit une interface standardisée pour le consentement à la vie privée.