Non risolvibile via firmware il problema della crittografia AES 256-bit per i SandForce SF-2281 - [NEWS] | Stampa

http://www.nexthardware.com/produtto...1192265851.jpg

LSI ha confermato in un comunicato stampa che il controller SandForce SF-2281 non offre il corretto supporto per la crittografia AES-256 come in precedenza era stato affermato.

Diversamente dalle prime ottimistiche voci circolate in rete, il problema del circuito che gestisce la crittografia AES 256-bit non è risolvibile con una patch software, ma soltanto con una correzione hardware.

LSI vende i controller SandForce alla stragrande maggioranza di produttori di SSD e, molti di questi, tra cui Intel, hanno fatto annunci ufficiali riguardo a questo problema.

Intel al riguardo, ha annunciato che i clienti per il quale la mancanza della crittografia AES 256-bit possa costituire un serio problema, possono restituire i loro SSD Intel 520 entro il 1 ottobre 2012 ed ottenere indietro il denaro investito.

Intel sottolinea inoltre che lavorerà per il lancio di nuove unità SSD con l'AES 256-bit funzionante ed LSI conferma che sta cercando di risolvere il problema del SandForce SF-2281 nel più breve tempo possibile.

Kingston, che utilizza il controller SandForce SF-2281 in parecchie linee di prodotti, ha annunciato che i clienti possessori di SSD della serie SSDNow V 200 e KC100 possono contattare il servizio clienti per sostituire le proprie unità SSD con i modelli aggiornati e che i suoi tecnici stanno lavorando a stretto contatto con quelli LSI per risolvere il problema.

Per gli utenti normali che non utilizzano la crittografia AES o possono accontentarsi di una doppia crittografia AES a 128 bit, l'SF-2281 funziona correttamente, quindi il produttore non effettuerà sostituzioni su quei prodotti che pur montando il controller incriminato non sono certificati per funzionare con AES 256-bit.

http://www.nexthardware.com/img/grap...xthardware.jpg

Mi sembrano un po' in confusione ;confused

:ciaociao:

C'è anche da dire che LSI ha rilevato SandForce non da molto tempo e dovrà ancora entrare nei suoi asset per capirci qualcosa di più...

Ho idea che ricapitolare gli elementi di questa vicenda non possa che far bene e soprattutto non possa che mettere correttamente
nella condizione di comprendere il nocciolo, le rilevanze e i veri artefici della creazione di questo macroscopico problema.


Alla fine del 2010 SandForce presenta la nuova e potente famiglia di controller SF-2000.

Nell'immagine seguente è descritta la rappresentazione del sistema di sicurezza sviluppato e implementato su tutti i modelli di
controller SandForce SF-20xx:

Allegato 11228

Come si riesce a intravedere, la doppia crittazione indicata da SandForce come rivoluzionaria feature, comprende l'utilizzo in hardware
di ben due diversi ed indipendenti motori crittografici.

Sul versante memorie Flash (in verde a dx dell'immagine) i dati vengono crittografati utilizzando un più semplice motore CTR-AES 128bit,
mentre sul versante canale SATA (in rosso a sx dell'immagine) viene invece fatto uso di un motore XTS-AES indifferentemente a 128
o 256bit. In questo modo, i dati che attraversano i controller della famiglia SF-2000, vengono crittografati due distinte volte, fornendo
la doppia crittazione.

L'engine CTR-AES (Counter-AES) è un classico della crittografia; rappresenta in definitiva una variazione della modalità OFB
(Output FeedBack); viene infatti utilizzato un contatore ed è previsto che il blocco cifrato sia in seguito modificato in un aderente flusso
cifrato: ciò permetterà di generare i blocchi susseguenti tramite la crittazione dei successivi valori di quel contatore. Per giungere alla
sicurezza intrinseca di CTR AES-128 si ha necessità di una chiave da 128bit.

Il motore XTS-AES (XEX-based Tweaked-Codebook mode with Ciphertext Stealing), invece, rappresenta una evoluzione della modalità XEX
(Xor-Encrypt-Xor). La modalità XTS ha iniziato ad esser presa in considerazione solo a partire dal 2007 ed in buona sostanza prevede il
supporto per settori di dimensioni non divisibili direttamente tramite la dimensione del blocco cifrato. Ha anche dalla sua, la particolarità di
creare una soluzione più efficace e sicura contro la manipolazione dei dati crittati, in quanto non prevede la possibilità di un controllo di accesso
o autenticazione.

Il metodo XTS presenta però un piccolo problema/particolarità: prevedere la necessità di far uso di due diverse ed indipendenti chiavi di cifratura,
ognuna di egual lunghezza alla robustezza fornita. Per ovviare a questa particolare modalità operativa è generalmente previsto, quindi, che le due
chiavi vengano di fatto generate direttamente tramite la suddivisione della relativa chiave del blocco originario di cifratura.

Applicando questa modalità alla implementazione effettuata sulla famiglia di controller SandForce SF-2000, tale circostanza operativa comporta
inevitabilmente la necessità di utilizzare una chiave di dimensioni doppie rispetto alla robustezza intrinseca dell'algoritmo in sé: serve quindi una
chiave da 256bit per giungere alla robustezza offerta da XTS-AES 128 e, analogamente, di una chiave ampia 512bit per XTS-AES 256.


Allegato 11229

field-programmable OTP memory, Split-Channel Cell of 1T-Fuse bit


In questa modalità appare di rilevante importanza il corretto utilizzo di una complementare memoria di tipo OTP (One Time Programmable) in grado
di fornire costantemente la necessaria ed unica master key.

A questo punto, considerata la definitiva ammissione da parte di LSI, ho il serio e concreto dubbio che la memoria OTP presa in considerazione
all'epoca, sia stata implementata in hardware da SandForce essendo in grado, a motivo di qualche erronea valutazione progettuale, di tenere il
passo del controller fornendo efficientemente (real-time) chiavi di lunghezza da 256bit, quindi potendo solo garantire la robustezza di XTS-AES 128.


Ad ogni buon modo, e a prescindere dalla mia personale chiave di lettura, questa bella storiella permette di stabilire senza tema di smentita che:


1) LSI è una azienda sulla cui serietà si potrebbe facilmente scommettere (e vincere): i vertici sanno bene cosa sia accaduto e stia accadendo.
La condotta di LSI è stata esemplare nel mettere al corrente i propri clienti ed utenti di quanto scoperto, suo malgrado. Soprattutto, credo abbiano le idee ben chiare di cosa poter e dover fare per ovviare al problema;

2) che il medesimo concetto (di serietà) non si possa invece applicare al vecchio team societario e soprattutto agli ingegneri SandForce: sono
evidentemente stati loro (gli ingegneri) a creare con estrema leggerezza questa incredibile situazione dal punto di vista tecnico. Esistono, purtroppo, anche elementi per poter lecitamente pensare che il team al comando di SandForce fosse a conoscenza del problema ben prima dell'acquisizione da parte di LSI, ed abbia voluto tener i partner e gli utenti all'oscuro di tutto, verosimilmente
per non perdere la faccia.

SandForce - Technology - Automatic Encryption

:yeah