On 8/2/06, Flavio Visentin <THe_ZiPMaN@xxxxxxxxx> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> Un grosso conflitto tra DRM e OpenSource è il fatto che la chiave di > volta del DRM è l'utilizzo di chiavi crittografiche per certificare il > sw che viene eseguito.
Il che però non vedo come sia contrastante con l'Open source. Tant'è che vi sono implementazioni di DRM OpenSource :-)
Si, l'implementazione http://trousers.sourceforge.net/ , però io mi riferivo al sw protetto dal DRM, non all'implementazione del sistema DRM.
> Queste chiavi risiedono nel TPM, e sono segrete.
Qui stai facendo MOLTA confusione tra due concetti nettamente distinti. I DRM sono una cosa, il TPM è tutt'altro strumento.
Ne sono conscio, il TPM è un dispositivo hw che PUO', tra le altre cose, essere usato per un'implementazione hw di un sistema di DRM.
> Io lo capisco per analogia come se il TPM fosse una > smartcard, un repository sicuro per la chiave privata.
E difatti è esattamente questo.
> La GROSSA differenza è che la chiave privata in una smartcard è sotto > il controllo esclusivo dell'utente, mentre le chiavi sul TPM sono > sotto il controllo di chi distribuisce i contenuti.
Non è corretto. Anche nel caso del TPM le chiavi sono sotto il controllo dell'utente, al pari di una smartcard, e possono essere quindi caricate da altri supporti o generate all'interno del chip. La differenza è solo che esiste UNA chiave privata generata dal chip in fase di produzione la cui chiave pubblica è a disposizione del produttore. Questo lascia spazio a possibili utilizzi limitanti, come per esempio blindare l'uso di determinati prodotti su determinati computer.
Giustissimo, grazie della correzione; la mia considerazione era superficiale. Anche le SmartCard si prestano a procedimenti equivalenti. Le CNS che descrivevo qualche post fa, ma anche le CIE, le nuove carte di identità elettroniche, nascono con delle chiavi precaricate che non sono sotto il controllo dell'utente, e permettono la modifica del contenuto della carta solo a fonti fidate (il certificatore, o il ministero dell'interno).
Questo comunque non cambia i termini del problema, comunque. In moltissimi casi il fatto che le modifiche al sw possano essere rilevate, è importante; questo non significa necessariamente impedire al sw di venire eseguito. Il problema è che se si distribuiscono le chiavi, il concetto di "assegnamento di responsabilità" si perde.
> Nasce ovviamente il problema di come un sw modificato possa venir > autenticato dal TPM, e la GPLv3 mi pare suggerisca che le chiavi > vengano distribuite insieme al sorgente.
E questo è assolutamente assurdo, come giustamente detto da LT. Il programma è una cosa, la chiave è tutt'altra cosa. Quando il sorgente è aperto, ciascuno è libero di utilizzare la propria chiave come meglio crede, e l'unico motivo per cui serve diffondere una chiave è per utilizzare servizi di terzi. Ma il servizio non è detto che sia o debba essere open source.
Secondo me per tentare di limitare un "potenziale" problema come il TC, hanno usato dei mezzi inadeguati che generano *reali* problemi in casi già esistenti, come quello della macchina di voto.
Precisamente.
Ciao, Rob.
- -- Flavio Visentin GPG Key: http://www.zipman.it/gpgkey.asc
There are only 10 types of people in this world: those who understand binary, and those who don't. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux)
iD8DBQFE0NgPusUmHkh1cnoRAsWTAJ9v9wz//OqtkRtqAw/0dy2kh0htUwCfVlxf M/bGTHFJOT2mGArC9QnqRGs= =4ENW -----END PGP SIGNATURE----- -- Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO "subscribe" (o "unsubscribe") a mailto:linuxtrent-request@xxxxxxxxxxxxx
-- Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO "subscribe" (o "unsubscribe") a mailto:linuxtrent-request@xxxxxxxxxxxxx
