Cell: IBM pubblica informazioni relative all'architettura di sicurezza

[DevilsAdvocate]

Originariamente inviato da zephyr83

Scusa ma che c'entra se ci gira linux tranquillamente?

Palladium e' una mistura di crittazione del codice e di altre misure (come l'identificazione
ESATTA dell'utente in rete) proprietarie. Mentre il semplice fritz chip e' usabile da sistemi
"aperti" come linux o solaris, l'accoppiata Palladium/LaGrande e' proprietaria e quindi
girera' soltanto con software Microsoft, anche quando altri S.O. volessero esservi compatibili.
Questo sistema invece gira sotto specifiche "aperte" (almeno a livello software), permettendo
all'utente/al sistema operativo un maggiore controllo di cio' che vuole e cio' che non vuole...
(ovviamente i giochi masterizzati sono esclusi da questo discorso quanto se non piu' che
sulla Xbox360 in quanto su PS3 il supporto sara' bluray....)

[xeal]

@Yokoshima

Non si tratta di hw che si autoprotegge dal software, ma di hw che protegge software da altro software: nell'ambito di una consol è praticamente un drm hw inaggirabile (non credo proprio che si possa ridurre tutto ad un modchip o a qualcosa del genere, a meno di voler mettere mano al "pezzo di silicio" e ai circuiti interni dei vari componenti hw, salvo grossolani bug sfruttabili in particolari situazioni).


@May81

Il tuo bel software per "sbloccare i giochi" non sblocca un bel niente, perchè non avrà modo di comunicare/scambiare dati con l'area di lavoro del gioco: sarà l'hw a impedirglielo.


@DevilsAdvocate

Invece è proprio la filosofia di Palladium. Lo scopo di Palladium non è quello di far scomparire (in maniera diretta, almeno) il software opensource, né il freeware. Questo succederebbe nell'incarnazione peggiore di questa tecnologia, con l'hardware alla base di un meccanismo di certificazione del software da eseguire/non eseguire, attivo di default (e non più disattivabile) fin dall'avvio. Ma qualche problema potrebbe nascere comunque: ad esempio, una major potrebbe subordinare la fruizione di un qualche contenuto digiale su una specifica macchina alla presenza su quella macchina di un particolare sistema operativo con un ben determinato kernel, uno specifico player versione x.y.z e driver determinati, tutti "approvati" dalla major mediante certificazione come "sicuri". Chiaramente questo potrebbe aggiungere dei costi per dimostrare alla major che il proprio software rispetta il drm, è perfettamente integrato con "palladium", non consente alcuna manipolazione dei dati ecc. (non siamo ancora, comunque, allo scenario in cui l'hw controlla tutto il software dall'avvio e decide cosa può essere eseguito e cosa no; comunque, la possibilità di usare l'hw come base di un qualche meccanismo di certificazione/autenticazione del software è più che una leggenda metropolitana: le specifiche del TPM - parlando di trusted computing in genere, ma questo di IBM mi pare di capire che sia la "variante" con le funzioni del tpm almeno in parte integrate nel processore - fanno un' accenno a tal proposito, dicendo che non si tratta di una funzionalità prevista, ma di una possibilità che non si vuole rendere incompatibile con le specifiche, da cui appunto il cenno... che a me sembra leggermente sibillino).

Personalmente, l'approccio alla "protezione" (termine che ritengo più appropriato rispetto a "sicurezza") del trusted computing non mi piace affatto. Come base di un qualunque DRM hardware trovo che sia un uso eccessivamente invasivo e inaccettabile: a differenza del software, l'hardware non viene concesso in licenza, ma venduto, la proprietà dell' "oggetto" passa integralmente all'acquirente, che può disporne come più gli aggrada, può rivenderlo (con un software in genere non si può fare legalmente), può overcloccarlo e perfino effettuare delle modifiche ( invalidando la garanzia, ma non infrangendo alcuna legge e/o "condizione di vendita", come invece accadrebbe con una qualsiasi manipolazione del software licenziatogli).

Di conseguenza ritengo oltremodo scorretto usare l'hardware - di proprietà dell'utente - per proteggere il software - non di proprietà dell'utente - dalle possibili manipolazioni operate dall'utente stesso, a vantaggio esclusivo di chi sfrutta il DRM hardware. Ancora: il meccanismo di crittografia alla base del trusted computing prevede che le chiavi di decodifica (in questo caso specifico la root key) vengano "celate" dall'hardware all'utente nonchè legittimo proprietario dello stesso; tuttavia, in virtù del "rapporto di proprietà" (passatemi l'espressione) tra l'utente/proprietario e la macchina/oggetto posseduto, ritengo che quest'ultima "non abbia il diritto" di nascondere alcuna informazione al suo legittimo proprietario; inoltre, essendo la ciascuna delle chiavi in questione, nella loro forma di "dato memorizzato", nient'altro che uno stato (o un'insieme di stati) di una porzione dell'hardware, ritengo si possa sostenere che appartenga anch'essa al proprietario dell'hardware (il quale rimane tale qualunque sia lo stato fisico di quest'ultimo, quindi il dato che vi è memorizzato) quindi, a maggior ragione, non trovo ammissibile che la conoscenza del dato binario venga negata in alcun modo al proprietario dell'hardware.

Un meccanismo simile può essere al più tollerabile in una consol di gioco la quale, essendo generalmente venduta sottocosto, si potrebbe sostenere essere ancora "parzialmente" di proprietà del produttore, o quantomeno si potrebbe sostenere che si tratta di un compromesso accettabile per acquistare la consol ad un prezzo inferiore al valore di mercato, se non al costo di produzione; tuttavia, dubito che qualcosa del genere si potrà mai sostenere a proposito di un personal computer. Per tanto, ritengo che l'uso dell'hardware, di proprietà dell'utente, per impedire atti di pirateria da parte di questi sia illegittimo tanto quanto la pirateria in sè. Cosa dicevano alla HispaSec a proposito del rootkit di Sony? Che non si può combattere il fuoco con il fuoco? Poi, per restare in tema di rootkit, non vedo come questo meccanismo possa proteggere l'utente dal comportamento "simil rootkit" (passatemi ancora l'espressione) di un componente installato da un qualche software "autorizzato" (insomma, una versione "aggiornata" con firme digitali dell'orpello installato da sony, per intenderci, anche se probabilmente non avrebbe alcuna utilità, visto che le sue funzioni verrebbero praticamente svolte dalla macchina...).

Per quanto riguarda gli usi cosiddetti "professionali" della tecnologia alla base del trusted computing, spesso sbandierati come possibile campo d'uso positivo e desiderabile, francamente mi sembra ancora peggio, almeno nella concezione attuale (che è quella, a mio modo di vedere, che meglio si presta all'uso come drm hardware). Francamente non credo che ci sia un solo ambito d'utilizzo, in tal senso, in cui l'uso generalizzato di questo tipo di crittografia sui dati, e in particolare per lo storage non temporaneo, in cui i vantaggi superino i (potenziali o concreti) svantaggi.

Infatti, da specifiche il TPM (o chi per esso) è il vero "proprietario" delle chiavi generate e le custodisce gelosamente, "occultandole" (almeno per quanto riguarda la parte privata) a tutti gli utenti, siano essi semplici user oppure l'owner della macchina: non c'e modo di conoscerle, nè di trasferirle su altre macchine o di imprimerne di note dall'esterno (a parte l'endorsement key del produttore). Questo vuol dire che diventa praticamente impossibile perdere dati sensibili in seguito allo smarrimento/furto di un portatile, o la cessione degli stessi (spionaggio industriale) perchè fruibili e registrabili in chiaro da un dipendente, o delle chiavi in suo possesso (tutt'al più questi può conoscere le chiavi pubbliche); MA vuol dire anche che la "vita" dei dati così protetti diventa strettamente dipendente da quella della macchina sulla quale vengono criptati, ovvero si frigge la scheda madre --> posso buttare l' hard disk.

E se questo può essere un rischio tutto sommato accettabile in ambito home, dove il rischio può essere non maggiore di quello legato alla rottura dell'hd e i dati persi non più importanti di quelli che talvolta lo stesso utente è disposto/costretto a perdere quando deve ricorrere al classico "formattone" per risolvere un problema (o non sa fare altro per risolverlo), ritengo non lo sia assolutamente in ambito professionale, dove, se è vero che un supporto col tempo possa ugualmente diventare inutilizzabile, è piuttosto improbabile che ciò avvenga contemporaneamente per tutti i supporti con tutte le copie di backup, cosa che invece accadrebbe per tutte le copie effettuate con quella macchina e protette con questo sistema, e i dati persi potrebbero essere critici.

A mio modo di vedere, le possibili soluzioni a questo... "piccolo inconveniente" sono essenzialmente due:

- aumentare il numero delle macchine adibite allo storage, soluzione che non annulla del tutto il rischio (ma lo riduce), però, in compenso, aumenta i costi, e introduce un po' di problemini da risolvere, si va dal/i semplice/i file server da associare al principale e usare come primo backup con schedule fisso (e la necessità di fare la copia di backup, criptata in questa ipotesi, degli stessi dati ma per ciascuno di questi "backup server" - per fronteggiare il doppio problema del possibile guasto del disco e del tpm), alla precauzione forse più paranoica che potrebbe prevedere l'utilizzo di più file server (in numero proporzionale al grado di paranoia/sfiducia nella macchina e in questo meccanismo di protezione dei dati e alla criticità degli stessi) per creare una sorta di mirroring, con scrittura dei dati su più macchine e controllo di coerenza dopo la scrittura (ma anche in lettura, nell'implementazione più pessimistica, per scongiurare la corruzione dei dati su una macchina o per testare saltuariamente l'efficienza dell' "apparato" ed individuare rapidamente eventuali problemi per procedere alla sostituzione tempestiva dell'elemento difettoso - e dei suoi backup criptati - contando sul funzionamento contemporaneo degli altri mirror dei dati), insomma, alcuni (anche molti) dei problemi connessi alla gestione di un filesystem distribuito (si può pensare alla questione della coerenza delle eventuali copie sparse nelle cache dei vari nodi, per velocizzare l'accesso ai dati da parte di più utenti - niente di trascendentale o di nuovo, per carità, solo non semplicissimo, quindi potenzialmente anche più esposto a bug nell'implementazione degli algoritmi di gestione, questi ultimi direi ben noti), con in più la complicazione della crittografia on the fly, che per quanto veloce, grazie al chip dedicato, potrebbe causare qualche rallentamento relativamente piccolo (o, in estremo, anche relativamente grande), laddove si debbano gestire molti accessi in lettura e/o scrittura più le verifiche sulle scritture, ovvero molte comunicazioni criptate tra diverse machine ciascuna con la propria coppia di chiavi da gestire. Rimane il problema, o se non altro il fastidio, sicuramente lavoro in più, di dover creare (in forma criptata) molti backup per ciascun mirror (ciascuno dei quali leggibile finchè la macchina su cui sono stati criptati funziona correttamente), problema (o inconveniente) che in qualche misura mi si proporrebbe anche laddove avessi una fiducia cieca sul funzionamento eterno della macchina, o quanto meno di quel componente delegato alla crittografia (ad esempio, se il tutto fosse integrato nel processore e questo risultasse funzionante basterebbe "trapiantarlo" in un'altra macchina compatibile - se disponibile o ancora in produzione/commercio), nel momento in cui dovessi (o semplicemente volessi) aggiornare le mie macchine, e in particolare quelle dedicate allo storage, ad esempio per naturale obsolescenza, per adeguare il parco hardware alle mie nuove esigenze, o per guasti (non relativi alla parte dedicata alla crittografia, che ho supposto eterna o presunta tale), dovrei provvedere alla decriptazione di tutti i dati prodotti e archiviati, allo storage temporaneo in chiaro (con i rischi del caso, quegli stessi che il Trusted Computing vorrebbe debellare) e alla successiva crittografia con il nuovo hardware e creazione dei nuovi backup (in forma criptata), buttando via quelli vecchi (in senso metaforico, o letterale, se il supporto non dovesse essere di un tipo riscrivibile; la potenza del meccanismo hardware garantisce che, comunque, nessuno, venendo in possesso materiale delle copie criptate possa farci alcunchè, mentre la macchina sostituita può essere tranquillamente rivenduta una volta revocate tutte le chiavi). Insomma, l'uso "puro" della tecnologia trusted non mi piace per niente;

- mantenendo alcune copie in chiaro (da custodire sotto chiave) o criptate con tecniche "tradizionali" ( = software), da custodire "di persona": sarebbe la soluzione più semplice, economica, attuabile, MA decreterebbe il FALLIMENTO della filosofia alla base del trusted computing, che vuola la totale delega all'hardware dei compiti relativi alla crittografia e protezione dei dati, ivi compresa la custodia di tutte le chiavi usate, vincolandone di fatto la validità e l'efficacia al funzionamento efficiente della macchina. A questo punto preferirei di gran lunga un TPM (o chi per esso) in grado di funzionare come un semplice reposiroty per chiavi generate in qualunque modo, sia esso software o hw (ad opera del TPM stesso), trasferibili a qualunque altra macchina e uniche per più macchine, MA ugualmente protette dall'uso non autorizzato e da modifiche/appropriazioni (trasferimenti ad altre macchine o copie su un qualsiasi supporto di memorizzazione) non autorizzate, cioè ad opera di utenti diversi dall'owner, in modo da avere poche chiavi da gestire e custodire al di fuori del sistema hardware e da parte di pochi autorizzati, con le stazioni di lavoro adeguatamente protette dall'hardware e i backup sempre validi... peccato che ciò non sia possibile. La crittografia completamente gestita dall'hardware e in maniera "trasparente" (o per meglio dire invisibile e inaccessibile), in realtà, credo che possa avere degli usi validi, purchè transitori: ad esempio, potrebbe servire per gestire connessioni remote occasionali - come supporto a SSL o a un qualsiasi protocollo sostitutivo e basato integralmente sulla crittografia asimmetrica - o in abbinamento alla virtualizzazione hardware, su un server, per proteggere i dati di esecuzioni differenti per utenti differenti da vulnerabilità, in caso di rilocazione dinamica delle risorse tra le macchine virtuali, ma in ogni caso non per gestire l'archiviazione permanente.

Chiaramente, questo è il mio personale punto di vista.

[liviux]

Scusate un piccolo Fuori Topico.

Originariamente inviato da xeal

...
Chiaramente, questo è il mio personale punto di vista.

33 righe, 2055 parole, 13859 caratteri!
Sono impressionato! C'è un premio per questo genere di record?
Comunque ora me lo stampo e questa sera me lo leggo con calma...

Originariamente inviato da liviux

Scusate un piccolo Fuori Topico.

33 righe, 2055 parole, 13859 caratteri!
Sono impressionato! C'è un premio per questo genere di record?
Comunque ora me lo stampo e questa sera me lo leggo con calma...

Concordo (ma che risoluzione usi per vedere solo 33 righe? io a 1280x1024 ne vedo mille mila). Il post più lungo che abbia mai visto

[liviux]

Originariamente inviato da ekerazha

Concordo (ma che risoluzione usi per vedere solo 33 righe? io a 1280x1024 ne vedo mille mila). Il post più lungo che abbia mai visto

Naturalmente uso tre monitor 21" affiancati, ciascuno a 2048x1536, con un font da 6 punti. Non lo fanno tutti?

P.S.: basta contare i newline presenti nel testo, indipendentemente dalla visualizzazione. Chiuso il FT.

[xeal]

Eh, eh, avete ragione, ho scritto un po' troppo e me ne scuso. Il fatto è che l'argomento, e cioè questo nuovo concetto di "sicurezza" mi ispira sempre molto (e non bene), e poi era da un po' che non partecipavo a thread correlati... Insomma, mi sono lasciato trasportare

[mjordan]

Originariamente inviato da Apace

Il Cell sarà usato anche nei server, e non solo. Da wikipedia :
http://it.wikipedia.org/wiki/Cell_%28processore%29
"Cell è una tipologia di processori sviluppati da IBM in cooperazione con Sony e Toshiba. La famiglia di processori Cell è sviluppata per permetterne un utilizzo quasi universale. Questi nuovi processori dovrebbero essere in grado di coprire i mercati che vanno dalle applicazioni dedicate (embedded) fino al mercato dei mainframe. I processori sono progettati per utilizzare la computazione parallela e la Sony prevede di utilizzarli per la sua nuova console, la PlayStation 3."

Bhè, con 8 core non si poteva certo ipotizzare un'esecuzione seriale.
Già vedo i titoli di coda. "Apple passa ai processori Cell: Steve Jobs dichiara che il passaggio porterebbe incrementi del 55% rispetto ai processori Intel. MacOS-X supporta già da tempo quest'architettura, la migrazione sarà facilitata da un'apposita versione di Rosetta, denominata per l'occasione Dura-Cell. La comunità Mac è alle stelle. Finalmente i Mac non potranno, ancora una volta, essere considerati comuni PC"

[mjordan]

Originariamente inviato da mortimer86

P.S.: Nel documento della IBM non è minimamente accennato il TDP, se ne sa qualcosa?

Avevo letto, diverso tempo fa, che si parlava di 85W. Ora mi hai fatto ritornare in mente la questione. E' parecchio tempo che cerco ma non ho trovato nulla a riguardo. Probabilmente il vero TDP lo sapremo solo nelle versioni server, quello della PS3 forse non verrà mai reso ufficiale.