Una startup healthcare può impiegare mesi per progettare un workflow mobile sicuro, per poi scoprire che il telefono di un tester con jailbreak ha esposto i dati dei pazienti tramite screenshot e cache locali. Contemporaneamente, una debug build del pannello di amministrazione Electron potrebbe essere rilasciata con una chiave API incorporata nel bundle. Entrambi gli incidenti riguardano la crittografia, ma nessuno dei due si risolve aggiungendo una singola libreria di cifratura.
La crittografia delle app è un sistema di decisioni. I team devono decidere come proteggere i dati archiviati, come si muovono tra i sistemi, dove risiedono le chiavi, cosa può estrarre un attaccante dal pacchetto dell'app, come il runtime risponde al tampering e come gli update firmati preservano tali garanzie. Un buon punto di partenza è una checklist di sicurezza OTA per app Capacitor che mappi i dati sensibili, i confini di fiducia, le capacità del client e i possibili percorsi di abuso.
Le applicazioni mobile e cross-platform operano in un ambiente insolitamente esposto. I dispositivi escono dall'ufficio, i build possono essere copiati o sideloadati, i file locali possono essere ispezionati e i tool di reverse-engineering sono facilmente reperibili. Le sezioni seguenti analizzano il modello passo dopo passo: dallo storage al trasporto, fino alla protezione delle chiavi di piattaforma, alla segretezza lato client, alla compliance e alle operazioni di rilascio.
Indice dei contenuti
- Perché la crittografia delle app è più importante che mai
- Crittografia At-Rest vs In-Transit
- Proteggere Code, dati e segreti nell'app
- Considerazioni sulle piattaforme iOS, Android, Capacitor ed Electron
- Key Management e i limiti della segretezza lato client
- Implicazioni normative e di compliance
- Errori comuni e best practice per la sicurezza
- Mettere tutto insieme nel tuo piano di crittografia
Perché la crittografia delle app è più importante che mai
Una web application solitamente mantiene gran parte della logica sensibile e dei segreti su un'infrastruttura controllata dall'organizzazione. Una mobile application invia code, asset, configurazioni e logica di gestione dati su un dispositivo che appartiene a qualcun altro. Un'applicazione Electron ha un problema simile, poiché il suo JavaScript, le risorse e i file pacchettizzati possono essere ispezionati da un utente che può eseguire l'app.
Questo cambia il perimetro di sicurezza. Il client è utile, ma non è una vault. La crittografia può proteggere le informazioni da un'ispezione superficiale e rendere meno utili i file rubati, ma l'app avrà comunque bisogno di accedere al plaintext in un certo momento. Un attaccante che controlla il dispositivo può osservare gli input, ispezionare la memoria, strumentare le API o modificare l'esecuzione.
Consideriamo l'esempio sanitario. Crittografare un database può proteggere i record copiati dal disco, ma non impedirà a un runtime compromesso di mostrare record decifrati a un processo malevolo. Crittografare il traffico di rete può proteggere la richiesta di un medico mentre viaggia verso il backend, ma non proteggerà un export locale dopo che l'app lo ha salvato in una cache non protetta. Una chiave nascosta in un JavaScript minificato rimane recuperabile se l'applicazione deve utilizzarla.
Regola pratica: Considera ogni protezione lato client come uno strato che riduce l'esposizione, non come la prova che il dispositivo sia affidabile.
Un design completo solitamente combina:
- Protezione dei dati a riposo, per database, file, cache, preferenze e documenti scaricati.
- Protezione dei dati in transito, per richieste, sincronizzazione, distribuzione degli update e comunicazione service-to-service.
- Storage delle chiavi di piattaforma, per evitare che le chiavi di cifratura restino in file applicativi comuni.
- Code e protezioni runtime, inclusi obfuscation, controlli di integrità, misure anti-debugging e un'adeguata validazione dei certificati.
- Un canale di update controllato, poiché un rilascio firmato deve preservare i presupposti di sicurezza incorporati nelle versioni precedenti.
- Controlli di compliance documentati, inclusi ownership, evidenze, monitoraggio e procedure di risposta.
Gli obblighi normativi aumentano la pressione, ma migliorano anche la disciplina ingegneristica. GDPR, HIPAA, PCI DSS e SOC 2 non riducono la crittografia a una semplice spunta su una checklist. Richiedono che i team comprendano cosa stanno proteggendo, come vengono gestite le chiavi e come dimostrare che le misure di sicurezza funzionino come previsto.
Crittografia At Rest vs In Transit
Pensa a un documento riservato inviato per posta raccomandata. La busta sigillata protegge il messaggio durante il trasporto. Una volta aperto dal destinatario, il documento avrà comunque bisogno di un archivio blindato. La crittografia in transit protegge il movimento. La crittografia at rest protegge l'archiviazione. La busta e l'archivio risolvono problemi diversi.
Crittografia At-rest
La crittografia at-rest si applica quando i dati risiedono su un dispositivo, disco del server, backup, database o volume rimovibile. Sulle piattaforme mobile, le protezioni del sistema operativo possono crittografare parti del dispositivo automaticamente, ma la tua applicazione deve comunque scegliere location di storage sicure, controlli di accesso e modalità di utilizzo delle chiavi. I file sensibili dell'app dovrebbero usare la crittografia supportata dalla piattaforma e chiavi conservate in store protetti, invece di una chiave scritta accanto ai dati crittografati.
In questo contesto la crittografia autenticata è fondamentale. OWASP raccomanda l'uso di API crittografiche della piattaforma, storage delle chiavi basato su hardware dove disponibile e modalità autenticate come AES-GCM o AES-CCM, che aiutano a rilevare manomissioni e a nascondere i contenuti. Le stesse linee guida raccomandano di proteggere i dati sensibili sia a riposo che in transito, salvando i dati privati nello storage interno ed evitando algoritmi crittografici proprietari a favore delle implementazioni della piattaforma ("Cheat Sheet per la sicurezza delle applicazioni mobile OWASP).
I dettagli pratici variano in base alla piattaforma. iOS offre Data Protection e Keychain. Android fornisce opzioni basate su Keystore e librerie per gestire file criptati. Le applicazioni desktop dipendono maggiormente dalle credenziali del sistema operativo e dai controlli di accesso locali. I team che lavorano con file in un ambiente Chromium Embedded Framework possono anche consultare le best practice per lo storage dei documenti CEF per esaminare i confini di storage oltre il cifrario stesso.
Crittografia in transito
La crittografia in transito protegge richieste e risposte durante il passaggio nelle reti. Una connessione TLS configurata correttamente aiuta a impedire che un intermediario legga o modifichi il traffico dell'app, ma TLS funziona solo se il client valida correttamente il server e il backend presenta un certificato affidabile. Un controllo del certificato disabilitato, un fallback non sicuro o un endpoint accidentalmente in chiaro possono compromettere la protezione prevista.
Il certificate pinning può aggiungere un ulteriore livello di verifica in scenari mobile selezionati, specialmente quando il team gestisce le operazioni sui certificati e ha un piano di recovery per la rotazione. Non sostituisce un corretto TLS, e un pin errato può bloccare gli utenti legittimi. I team che sviluppano con Capacitor possono esaminare SSL pinning per app Capacitor prima di decidere se i compromessi operativi sono adatti alla propria applicazione.
I modi di guasto sono complementari. La sicurezza del trasporto non proteggerà un database copiato da un dispositivo smarrito. La crittografia dello storage non proteggerà una password inviata tramite una connessione compromessa. Progetta entrambi i percorsi, poi testa i punti in cui appare il plaintext, inclusi log, screenshot, file temporanei, crash report, contenuto degli appunti e code di sincronizzazione.
Proteggere Code, Dati e Segreti nell'App
I team spesso usano i termini “encryption”, “obfuscation” e “hardening” come se descrivessero lo stesso controllo. Non è così. Ognuno affronta un'azione diversa dell'attaccante, e confonderli crea un falso senso di sicurezza.
Obfuscation e minificazione rendono code più difficile da leggere. Possono aumentare il costo per clonare un'applicazione o comprendere la business logic, ma non rendono un segreto inaccessibile a un'app che deve usarlo. Una chiave API in un bundle JavaScript, una credenziale di firma in un archivio o un valore ricostruito da una funzione prevedibile possono comunque essere estratti. Hermes bytecode ed Electron asar gli archivi potrebbero essere meno comodi da ispezionare rispetto ai file sorgente, ma il packaging non equivale alla segretezza.
Crittografia dei dati protegge i contenuti dell'utente e le credenziali locali durante l'archiviazione. Dovrebbe utilizzare le API crittografiche della piattaforma e chiavi memorizzate in Keychain, Keystore, Secure Enclave, StrongBox o strutture equivalenti del sistema operativo, dove disponibili. Le linee guida di OWASP per il testing crittografico sconsigliano di inserire password o chiavi nel code sorgente e sottolineano che i segreti rimasti sul client possono essere estratti (Testing crittografico OWASP MASTG).
Protezioni runtime cercano condizioni che aumentano la probabilità di tampering o abuso automatizzato. Segnali di jailbreak e root, rilevamento debugger, controlli di integrità dell'app, attestation e validazione dei certificati possono rendere gli attacchi più difficili o fornire un segnale di risposta. Nessuno di questi rende un dispositivo affidabile. Un attaccante determinato può modificare i controlli, e un utente legittimo potrebbe attivare un'euristica.
| Livello di protezione | Cosa protegge | Cosa non riesce a fermare |
|---|---|---|
| Offuscamento Code | Leggibilità e clonazione facile della logica applicativa | Estrazione di segreti a cui l'app può accedere |
| Crittografia dei dati | Riservatezza e integrità dei dati archiviati selezionati | Esposizione in chiaro dopo una decrittazione legittima |
| Protezioni runtime | Manomissioni, debugging e abuso automatizzato | Un attaccante esperto che controlla il runtime |
Un design più sicuro mantiene i segreti critici sul server, fornisce al client credenziali con scope limitato e cripta solo i dati locali che richiedono l'accesso offline. La gestione dei token richiede una revisione specifica di scadenza, revoca, refresh e platform binding. La guida allo storage sicuro dei token per sviluppatori mobile è utile per trasformare queste decisioni in requisiti di implementazione.
Gli approcci ingenui falliscono perché proteggono l'apparenza del segreto invece del suo ciclo di vita. Fare l'XOR di un valore nel codice code, dividere una chiave in più file o fare affidamento sulla minificazione JavaScript non cambia il fatto che l'app in esecuzione debba ricostruire e usare quel valore.
Considerazioni sulle piattaforme per iOS, Android, Capacitor ed Electron
Lo stesso design di crittografia si comporta diversamente tra i runtime perché ogni piattaforma espone diversi key store, API, confini di isolamento e meccanismi di recovery. Un'astrazione cross-platform può semplificare la code dell'app, ma non può eliminare queste differenze.
Piattaforme mobile native
Su iOS, il Keychain offre uno storage protetto per le credenziali, mentre Secure Enclave può isolare determinate operazioni di chiave dal processore principale dell'app. L'applicazione deve comunque selezionare i controlli di accesso in base ai requisiti di usabilità, come se i dati debbano essere disponibili dopo l'autenticazione del dispositivo o solo dopo l'autenticazione dell'utente.
Android Keystore fornisce un percorso hardware-backed sui dispositivi supportati, e StrongBox può offrire un ambiente isolato ancora più sicuro dove disponibile. I team Android dovrebbero considerare le capacità del dispositivo, il comportamento del backup, i requisiti di autenticazione e i segnali di attestation. Il supporto hardware non è uniforme, quindi l'app deve avere una policy di fallback definita invece di dare per scontato che ogni dispositivo offra la stessa protezione.
Shell cross-platform
Le applicazioni Capacitor combinano il web code con le capacità native tramite un bridge. Quel bridge è un confine di sicurezza, non un semplice layer di comodità. localStorage, IndexedDB e le normali web preferences non dovrebbero essere trattate come store di segreti criptati di default. Un team deve scegliere esplicitamente un plugin di storage nativo o implementare un modulo nativo che utilizzi le strutture di chiavi protette della piattaforma.
Electron ha un modello di minaccia differente. Il suo renderer gestisce i contenuti web, mentre il main process ha privilegi più ampi, quindi le operazioni sensibili dovrebbero restare fuori da un renderer esposto. L' safeStorage può utilizzare la protezione delle credenziali del sistema operativo, ma la sicurezza risultante dipende dal sistema operativo host, dall'account utente, dalla configurazione del desktop e dall'isolamento dei processi. La chiave non è isolata automaticamente via hardware come avviene su una piattaforma mobile.
| Piattaforma | Key Storage | Crittografia API | Modello di minaccia predefinito |
|---|---|---|---|
| iOS | Keychain e, se supportato, Secure Enclave | Crittografia Apple e Data Protection | Dispositivo e app sono separati, ma un dispositivo o runtime compromesso può osservarne l'uso |
| Android | Keystore e, se supportato, StrongBox | Crittografia Android e componenti Jetpack security | Le capacità hardware e software variano in base al dispositivo |
| Capacitor | Storage nativo selezionato tramite plugin o bridge custom code | Web API e API native della piattaforma | Gli asset web girano in una shell nativa e non ereditano automaticamente lo storage sicuro |
| Electron | Funzionalità di gestione delle credenziali OS tramite API come safeStorage |
API applicative compatibili con Node e Chromium | L'esposizione del renderer e l'accesso a livello host sono criticità centrali |
I team dovrebbero documentare il comportamento per ogni target invece di descrivere il prodotto come "crittografato su tutte le piattaforme". L' approccio di Capacitor alle differenze tra piattaforme aiuta a definire il bridge come un punto in cui le decisioni specifiche della piattaforma devono rimanere visibili.
Key Management e i limiti della segretezza lato client
La crittografia protegge i dati solo se il key management protegge le chiavi. Un ciclo di vita efficace ha cinque fasi: generazione, distribuzione, storage, rotazione e revoca. Ogni fase presenta un diverso tipo di fallimento.
Genera le chiavi tramite API crittografiche di una piattaforma o di un server affidabile. Distribuiscile tramite un protocollo autenticato invece di includerle in un bundle. Conservale in una struttura protetta della piattaforma, dove possibile. Ruotale quando le policy, il rischio o i requisiti crittografici lo richiedono. Revoca l'accesso tramite autorizzazione controllata dal server quando un dispositivo, un account o una sessione non devono più decriptare i dati.
Il client è meno sicuro dell'infrastruttura per queste operazioni, poiché l'utente controlla il dispositivo e può potenzialmente ispezionare lo stato dell'applicazione. Una chiave gestita dal client può avere senso per i dati offline protetti da una passphrase derivata dall'utente, a patto che il prodotto accetti le conseguenze su recovery e usabilità. Ha molto meno senso per un token API che garantisce un ampio accesso al backend. Se un attaccante estrae quel token, la crittografia di un database locale non limiterà ciò che il token può fare da remoto.
L'envelope encryption separa la data-encryption key dalla master key. L'app può criptare un oggetto locale con una data key a breve scadenza, mentre un servizio di key management lato server o un sistema basato su HSM protegge la wrapping key. Un design di remote key-release può richiedere un dispositivo autenticato, un utente, una policy o un segnale di attestation prima di rilasciare il materiale necessario per la decriptazione. Questi pattern non rendono sicuro un client compromesso, ma riducono l'autorità permanente sul dispositivo.
OWASP identifica i dati sensibili locali come informazioni personali identificabili, materiale crittografico, segreti e chiavi API. Collega inoltre la crittografia ai controlli del ciclo di vita, come lo storage locale sicuro, la key rotation e la zeroization dopo l'uso. Il principio architettonico è semplice:
Mantieni i segreti di alto valore su sistemi controllati dal team. Fornisci al client solo la minima autorità necessaria per il task corrente.
Per i sistemi di rilascio, il key management si applica anche alla firma e alla consegna degli update. Un team dovrebbe definire chi può firmare un bundle, dove risiedono le credenziali di firma, come viene auditato l'accesso e come sostituire una credenziale di firma compromessa. La guida su come proteggere gli update OTA con il key management può aiutare a collegare la crittografia dell'app al ciclo di vita degli update.
Implicazioni normative e di compliance
I team di compliance solitamente non accettano la frase "l'app usa la crittografia" come prova sufficiente. Chiedono quali dati siano coperti, quali algoritmi e protocolli siano attivi, chi controlli le chiavi, come venga limitato l'accesso e come l'organizzazione rilevi eventuali derive di configurazione.
L'Articolo 32 del GDPR considera la crittografia una misura tecnica appropriata per ridurre i rischi, come indicato nel testo del GDPR dell'Unione Europea. L'obbligo si basa sul rischio, quindi l'organizzazione deve comunque collegare le proprie protezioni alla natura dei dati personali e all'ambiente di elaborazione. Un'app mobile che gestisce informazioni mediche, dati di identità o record finanziari necessita di una spiegazione valida su archiviazione locale, trasporto, accesso e incident response.
La Security Rule di HIPAA tratta la crittografia per le informazioni sanitarie elettroniche protette come una misura di sicurezza opzionale piuttosto che come un semplice controllo tecnico universale. Ciò significa che un'entità coperta o un business associate dovrebbe valutare se la crittografia sia ragionevole e appropriata, documentare la decisione e applicare misure alternative laddove non implementi tale protezione. La guida della HHS Security Rule fornisce il contesto normativo.
Il PCI DSS distingue tra i dati dei titolari di carta memorizzati e la trasmissione su reti aperte. I team dovrebbero mappare le decisioni sulla crittografia rispetto ai requisiti applicabili ed evitare di memorizzare i dati di pagamento inutilmente. La libreria documentale del PCI Security Standards Council è il posto corretto per verificare la terminologia e l'ambito attuali.
I revisori SOC 2 si concentrano sulle prove che i controlli siano operativi. Tali prove possono includere policy di key-management, configurazioni TLS, inventari dei cipher, access log, approvazioni delle modifiche, record degli incidenti, risultati dei test e la prova che i release firmati seguano il processo previsto. Un controllo documentato ma non monitorato potrebbe non dimostrare un'operatività efficace.
Il filo conduttore è la dimostrabilità. Crea la traccia delle prove mentre implementi la crittografia dell'app, non la settimana prima di un audit.
Errori comuni e Best Practice per la sicurezza
La maggior parte dei fallimenti nella crittografia nasce da normali decisioni ingegneristiche. Un developer ha bisogno di un token disponibile all'avvio, un team vuole che la ricerca offline sia veloce, o un processo di release necessita di un modo rapido per distribuire un hotfix. Il rischio emerge quando la scorciatoia diventa parte permanente del modello di fiducia.
Uno studio recente sui rischi mobile ha riportato che oltre il 60% delle app analizzate utilizzava crittografia insicura o obsoleta per i dati sensibili, mentre circa un terzo riutilizzava gli initialization vectors e 20% di valori statici hardcoded. Questi risultati spostano il quesito da "l'app cripta?" a "l'implementazione è in grado di preservare riservatezza e integrità durante l'uso reale?" ("Rapporto SC World sui rischi delle app mobile)
| Errore Comune | Best Practice |
|---|---|
| Hardcoding di chiavi API o chiavi di cifratura nel codice sorgente, bytecode o bundle | Mantieni le credenziali critiche lato server e usa lo storage protetto della piattaforma per i dati locali |
| Criptare un database SQLite lasciando cache, export, log o backup in chiaro | Mappa ogni copia di dati sensibili e applica la stessa policy di storage agli artefatti temporanei |
| Salvare i refresh token nel web storage ordinario | Usa lo storage delle credenziali della piattaforma, limita lo scope dei token e supporta la revoca lato server |
| Scrivere crittografia custom o inventare sistemi di obfuscation delle chiavi | Usa API di piattaforme verificate e modalità di cifratura autenticate |
| Disabilitare la validazione dei certificati per risolvere problemi di connettività | Configura correttamente TLS, poi valuta il pinning con un processo di recovery testato |
| Considerare la minificazione come protezione dei segreti | Rimuovi i segreti dal code client e usa l'obfuscation solo per aumentare i costi di reverse-engineering |
| Omettere i controlli di integrità dell'app e i segnali di attestation | Valida l'identità del rilascio dove opportuno e usa i segnali per regolare l'accesso o avviare una review |
| Consentire update non firmati o con controlli deboli | Firma gli artifact del rilascio, proteggi le credenziali di firma e monitora l'esito degli update |
Un report separato sulle minacce ha descritto gruppi di spyware che colpiscono account Signal e WhatsApp tramite spoofing di app e abuso dei telefoni sottostanti. Lo stesso report citava una valutazione delle minacce mobile in cui Android smartphone attacks were up 29% in H1 2025 compared with H1 2024 (La copertura di The Register sul report legato a CISA). La lezione non è che la crittografia sia fallita. Spesso gli attaccanti scelgono il dispositivo, l'account, la sessione o il percorso di aggiornamento perché questi livelli possono aggirare il ciphertext protetto.
Trasforma ogni pratica di hardening in una regola di rilascio automatizzata. La CI può rifiutare i pattern di secret noti, segnalare code crittografici custom, verificare gli step di firma, ispezionare i contenuti del bundle e richiedere una revisione di sicurezza quando cambiano le impostazioni di storage o trasporto. L'obiettivo è intercettare una decisione sbagliata prima che diventi una dipendenza rilasciata.
Mettiamo tutto insieme nel tuo piano di crittografia
Un piano di crittografia deve leggersi come un contratto di ingegneria. Deve dire cosa protegge l'app, dove risiedono le chiavi, quali componenti possono vedere il plaintext e come il team dimostra che i controlli restano attivi dopo ogni rilascio.
Inizia con classificazione dei dati. Contrassegna record, token, documenti, log, cache, backup e campi analytics in base alla sensibilità e alle esigenze di retention. Minimizza le copie locali prima di scegliere un algoritmo. I dati che non arrivano mai sul dispositivo non richiedono un design di storage sul dispositivo.
Poi documenta le decisioni su storage e trasporto:
- Schema at-rest: Scegli la crittografia autenticata, la gestione delle chiavi tramite piattaforma, le posizioni protette dei file, il comportamento del backup e la modalità di eliminazione o zeroizzazione.
- Protocollo in-transit: Definisci la configurazione TLS, la validazione dei certificati, la policy degli endpoint e se il pinning è adatto al threat model.
- Custodia delle chiavi: Procedure di generazione, accesso, distribuzione, rotazione, revoca, recupero e sostituzione d'emergenza dei record.
- Code e controlli runtime: Decidi quali protezioni di offuscamento, controllo dell'integrità, attestazione, rilevamento debugger e schermate sensibili implementare.
- Prove di audit: Registra inventari di configurazione, log di accesso, approvazioni dei release, risultati dei test, record degli incidenti ed eccezioni.
L'ordine è fondamentale. La classificazione dei dati determina cosa proteggere. Tale decisione modella lo storage e la custodia delle chiavi. I controlli di trasporto e update preservano poi il percorso tra i servizi fidati e il client. I team di Capacitor ed Electron dovrebbero ripetere la revisione per ogni target, poiché un key store nativo iOS, un'opzione Android hardware-backed, uno storage browser API e un sistema di credenziali desktop non offrono garanzie identiche.
L'update channel deve far parte di questo piano, non venire dopo. Un release firmato può preservare l'integrità di code, mentre il targeting controllato, la protezione dal rollback e l'osservabilità del release aiutano il team a intervenire quando un build o una configurazione vulnerabile raggiunge gli utenti. Revisiona il piano ogni volta che l'app aggiunge dati offline, cambia il plugin di storage, introduce un nuovo permesso backend o modifica il modo in cui gli update vengono firmati e consegnati.
Capgo offre live update firmati per applicazioni CapacitorJS ed Electron, con supporto per bundle criptati per code JavaScript e asset, canali di rilascio controllati, protezione dal rollback e osservabilità degli update per singolo dispositivo. Visita Capgo per valutare come un percorso di update controllato possa supportare il tuo piano di crittografia e governance dei rilasci.
