Secure Enclave e Android Keystore: Guida all’Hardware Binding nell’App IO

Nel percorso di digitalizzazione dell’identità promosso dall’architettura IT-Wallet, la sicurezza fisica dei dati sensibili ricopre un ruolo di primo piano. Comprendere il funzionamento di Secure Enclave e Android Keystore è fondamentale per qualsiasi sviluppatore che desideri implementare standard elevati di protezione crittografica sui dispositivi degli utenti. Per una panoramica sistemica dell’infrastruttura, rimandiamo alla nostra guida completa su architettura IT-Wallet e App IO.

Cosa sono l’Hardware Binding e i Moduli Crittografici Hardware

L’hardware binding garantisce che una coppia di chiavi asimmetriche sia vincolata fisicamente al chip crittografico del dispositivo mobile. Attraverso Secure Enclave e Android Keystore, le chiavi private non lasciano mai la memoria protetta dell’hardware e non possono essere estratte neppure in caso di compromissione del sistema operativo tramite root o jailbreak.

  • Apple Secure Enclave (SEP): Coprocessore isolato dedicato con crittografia AES e True Random Number Generator (TRNG) integrato.
  • Android Keystore con StrongBox: Chip hardware dedicato (HSM embedded) che gestisce chiavi crittografiche tramite isolamento TEE (Trusted Execution Environment) o StrongBox Keymaster.

Passo 1: Generazione delle Chiavi Protette da Hardware

Il primo step per collegare in modo sicuro la patente o la tessera sanitaria all’interno dell’applicazione consiste nel richiedere una coppia di chiavi crittografiche (tipicamente basate su curva ellittica SECP256R1) direttamente all’interno dell’ambiente sicuro.

Configurazione su iOS (Swift)

Su iOS, le impostazioni passano attraverso l’uso del framework Security e dei parametri di accesso sicuro:

let access = SecAccessControlCreateWithFlags(
    nil,
    kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly,
    [.privateKeyUsage, .biometryAny],
    nil
)

let attributes: [String: Any] = [
    kSecAttrKeyType as String: kSecAttrKeyTypeECSECPrimeRandom,
    kSecAttrKeySizeInBits as String: 256,
    kSecAttrTokenID as String: kSecAttrTokenIDSecureEnclave,
    kSecPrivateKeyAttrs as String: [
        kSecAttrIsPermanent as String: true,
        kSecAttrApplicationTag as String: "it.io.wallet.credentialKey",
        kSecAttrAccessControl as String: access!
    ]
]

Configurazione su Android (Kotlin)

Su Android, si sfrutta il KeyGenParameterSpec configurato per richiedere specificamente il binding hardware:

val keyPairGenerator = KeyPairGenerator.getInstance(
    KeyProperties.KEY_ALGORITHM_EC,
    "AndroidKeyStore"
)
val spec = KeyGenParameterSpec.Builder(
    "credential_alias",
    KeyProperties.PURPOSE_SIGN or KeyProperties.PURPOSE_VERIFY
)
    .setDigests(KeyProperties.DIGEST_SHA256)
    .setUserAuthenticationRequired(true)
    .setIsStrongBoxBacked(true)
    .build()
keyPairGenerator.initialize(spec)
keyPairGenerator.generateKeyPair()

Passo 2: Flusso di Attestazione e Firma Crittografica

L’utilizzo coordinato di Secure Enclave e Android Keystore permette all’App IO di comprovare che la richiesta di rilascio di un’attestazione provenga effettivamente da un dispositivo conforme.

  1. App Attestation: Viene prodotta una prova crittografica (DeviceCheck/DCAppAttest su iOS, Play Integrity con Key Attestation su Android) che certifica che la chiave privata risiede in hardware genuino.
  2. Challenge del Backend: Il server centrale invia un nonce univoco per scongiurare attacchi di tipo replay.
  3. Generazione della firma: L’utente autorizza l’operazione tramite dati biometrici (Face ID, Touch ID o impronta digitale); il chip sicuro valida la biometria localmente e rilascia la firma digitale.

Best Practice di Sicurezza e Risoluzione dei Problemi

Quando si integrano Secure Enclave e Android Keystore nei flussi applicativi, è opportuno adottare le seguenti precauzioni per evitare blocchi per gli utenti finali:

  • Gestione del fallback StrongBox: Su Android, se un dispositivo legacy non supporta isStrongBoxBacked, prevedere un fallback controllato sul TEE standard con verifica di livello di sicurezza.
  • Revoca delle credenziali al cambio biometria: Impostare l’annullamento automatico delle chiavi crittografiche se l’utente registra una nuova impronta o cambia PIN di sistema.
  • Isolamento per dominio: Non riutilizzare la stessa coppia di chiavi per documenti differenti; generare chiavi distinte per ciascun attributo rilasciato nel portafoglio.

Articoli simili