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

Visualizzazione dei risultati da 1 a 4 su 4
  1. #1
    S|culo S|lente! L'avatar di pippo369
    Registrato
    May 2001
    Località
    Mazara del Vallo
    Età
    55
    Messaggi
    7,758
    configurazione

    Predefinito Più grave del previsto il bug dei SandForce SF-2281 di cui si è tanto discusso in questi giorni.


    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.




  2. #2
    Daniele L'avatar di Trattore
    Registrato
    Jul 2011
    Località
    provincia Lecco
    Età
    48
    Messaggi
    9,787
    configurazione

    Predefinito

    Mi sembrano un po' in confusione


  3. #3
    Moderatore L'avatar di betaxp86
    Registrato
    May 2003
    Località
    Genova, Italy
    Età
    37
    Messaggi
    10,196

    Predefinito

    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ù...
    betaxp86


  4. #4
    ●⁞◌ Ȏrȉzzȏntέ Ðέglȋ ȨvέntȊ ◌⁞●
    Registrato
    Aug 2008
    Località
    Palermo
    Messaggi
    2,952

    Predefinito

    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:

    Clicca sull'immagine per ingrandirla

Nome:   SF-2000 AES-XTS_problem.jpg
Visite: 355
Dimensione:   98.6 KB
ID: 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.


    Nome:   Fuse-OTP_Memory.png
Visite:  614
Grandezza:  15.7 KB

    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


Informazioni Thread

Users Browsing this Thread

Ci sono attualmente 1 utenti che stanno visualizzando questa discussione. (0 utenti e 1 ospiti)

Tags

Regole d'invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
nexthardware.com - © 2002-2022