Una falla di sicurezza che ha fatto tremare il web, ma che non ha interessato Apple. Come mai Heartbleed non ha colpito iOS?
Nel 2011, Apple ha detto ai suoi sviluppatori che sarebbe stato ironico utilizzare la Common Data Security Architecture di OpenSSL, descrivendola come una reliquia della fine degli anni ’90. Quasi tre anni dopo da quella dichiarazione, sappiamo tutti che proprio OpenSSL è stato colpito da una grave falla che ha interessato gran parte dei fornitori di servizi e i loro utenti, ma non Apple.
Quando nel giugno del 2011 Apple ha dichiarato la sua intenzione di bocciare OpenSSL, non era certo a conoscenza di Heartbleed, visto che non esisteva ancora. Tuttavia, l’azienda era a conoscenza di altri problemi relativi ad OpenSSL, visto che questa architettura era già stata usata qualche anno prima da Apple.
Apple aveva infatti integrato il supporto per CDSA e OpenSSL nello sviluppo iniziale di Mac OS X. Eravamo nel 2004, e l’azienda raccomandava gli sviluppatori Mac di adottare CDSA, in quanto avrebbe migliorato le prestazioni generali del sistema, riducendo il numero di librerie necessarie per la crittografia.
A partire dal 2006, però, Apple ha iniziato a lavorare su una nuova API per la crittografia. L’idea era di utilizzare meno codice, migliorare le prestazioni e supportare l’uso simultaneo di più processori. Tale API sarebbe servita non solo per le future versioni di OS X, ma anche per iOS.
La volontà di realizzare questa struttura più snella e moderna era dovuta anche al bisogno di rispettare lo standard FIPS 140-2, necessario per vendere i dispositivi alle agenzia governative degli Stati Uniti.
Il primo passo è stato Common Crypto, un quadro di basso livello C di supporto ai principali algoritmi di crittografia Apple disponibili da OS X 10.5 e da iOS 5. Siamo nel 2011, proprio quando Apple consiglio ai propri sviluppatori di abbandonare OpenSSL.
Negli anni successivi, Apple ha migliorato queste sue architetture, proponendo soluzioni sempre più snelle e sicure.
In un documento del 2012, Apple spiega che il CDSA non segue le convenzioni di programmazione richieste da Apple, e per questo sia iOS che OS X includono API realizzate in casa che supportano un livello superiore di sicurezza.
Costruire un proprio software di sicurezza significava anche non dover più essere vincolati agli sviluppo esterni di un progetto open source come OpenSSL, che nonostante la sua importanza critica e il suo massiccio utilizzo, era gestito da un gruppo di pochissimi sviluppatori.
E’ la stessa Apple a scrivere agli sviluppatori che, malgrado OpenSSL sia comunemente utilizzato nella comunità open source, non fornisce alcuna API stabile di versione in versione. Per questo motivo, prosegue Apple, OS X e iOS utilizzato API realizzate dalla stessa Apple e sconsiglia quindi l’utilizzo delle librerie OpenSSL in OS X.
La preoccupazione principale di Apple, già dal 2011, era proprio questa: in caso di falla nella sicurezza, avrebbe dovuto attendere lo sviluppo di un progetto esterno e non controllabile. Invece, con API create in casa, questo problema non si poneva. Insomma, maggiore controllo, maggiore sicurezza.
Insomma, la lungimiranza degli ingegneri Apple ha avuto ragione, visto che oggi Heartbleed sta letteralmente preoccupando milioni di siti e di utenti.
In ogni caso, dobbiamo ricordare che anche OS X e iOS hanno avuto problemi di sicurezza, relativi sempre all’architettura SSL, ma proprio il fatto di poterla controllare “in casa” ha permesso ad Apple di correggere tutti i problemi in tempi brevi.