... cut ...
> Hai ragione, il 5823 non ha molto a che fare con i TPM, ma nemmeno il BCM5890! > Non vedo alcunchè che indichi che il BCM5890 aderisce alle specifiche TPM. >
veramente è dichiarato esplicitamente che è destinato alla creazione di Trusted Platform:
BCM5890 Secure Applications Processor
The ARM-based BCM5890 security applications processor is a single-chip, _trusted_ _platform_ solution capable of executing application software in a secure environment. The BCM5890's secure memory access system allows application code to be encrypted and digitally signed prior to being stored in off-chip memory. This feature allows for application software to be updated and downloaded in the field in a secure and trusted manner. Furthermore, the BCM5890 ensures that only authenticated software can be loaded and executed by
... cut ... vedi, noi tecnici siamo un po'pignoli. Se mi si cita un chip come TPM, io esigo che implementi le relative specifiche, e voglio sapere anche a che livello, 1.1 o 1.2 . Tutto il resto e' fuffa (o meglio, probabilmente una implementazione proprietaria fuori standard, fatta da Broadcomm).
> Questo invece si: > http://www.infineon.com/upload/Document/tpm1.2-hardware-pb.pdf >
Nel pdf che ho citato c'e' la dichiarazione esplicita di aderenza alle specifiche .
> > E secondo le specifiche TPM è fatto in modo tale da non poter essere > > usato come acceleratore crittografico. In particolare, non deve poter > > svolgere funzioni di crittografia a chiave simmetrica > > (che è quella > > usata per queste applicazioni). In pratica il TPM > > svolge velocemente il suo lavoro, in modo da non gravare la CPU, ma fa proprio > > solo quello. Non svolge la funzione di acceleratore crittografico a > > tua disposizione. > > Precisamente; ma l'accelerazione crittografica c'è eccome! > (Asimmetrica, ma anche opzionalmente simmetrica, vedi: > https://www.trustedcomputinggroup.org/specs/TPM/tpmwg-mainrev62_Part1_Design_Principles.pdf > "2.2.2 Cryptographic Co-Processor" > ) > Anche se non è esposta come funzione general-purpose.
no nella stessa sezione trovi " I TPM, per specifica, non devono esportare nessuna funzione crittografica _simmetrica_ (tipo DES, per intenderci) verso la piattaforma .." sempre se ho interpretato giusto : T€ -The TPM may symmetric encryption for internal TPM use but does not expose any symmetric algorithm functions to general users of the TPM.-
E' esatto. Ma "non esportare" e' ben diverso dal "non esistere".
> Quello che voleva dire Flavio è che è possibile implementare le stesse > funzioni offerte dal TPM in sw, ma che il TPM, essendo progettato per > queste, e dovendole fare in maniera massiva, è molto più efficiente.
per la funzione che è stato creato si ma non per altro
mah, qualcuno ha parlato di altro?
tecnicamente ed economicamente il TPM.
La crittografia _asimmetrica_ (a chiave pubblica, tipo RSA per intenderci) del
TPM viene usata solo dal TPM stesso per generare e gestire le proprie chiavi,
per firmare documenti e per cifrare le chiavi di cifra usate a loro volta da
_sistemi_ _esterni_ per cifrare i documenti.
Il ruolo tradizionale dei co-processori crittografici, come il Broadcom di cui
parlavamo, è invece proprio quello di svolgere funzioni di cifratura e
decifrazione simmetriche (ed asimmetriche) sui documenti degli utenti ("bulk
cryptography"), magari usando chiavi generate, gestite e conservate (cifrate)
dal TPM. Sono due ruoli indipendenti e complementari.Ci sono delle
funzionalità del TPM che devono necessariamente essere implemementate
in HW per non compromettere l'affidabilità dell'intera piattaforma,
come la memorizzazione delle chiavi all'interno del TPM stesso, ad
esempio. Il TP non è affatto un semplice acceleratore crittografico.
Nessuno in questo thread ha detto questo.
Il TPM è un oggetto che aggiunge alla piattaforma ospite delle funzionalità del tutto nuove e che non possono essere implementate in software od affidate ad altri componenti.
e perche' no? il TPM non fa niente di arcano, usa algoritmi perfettamente noti e pubblici, l'unica cosa e' che le fa al suo interno.
E quello che volevo dire è che in generale la crittografia si può gestire via software attraverso algoritmi altrettanto sicuri del fritz chip e senza compromettere la privacy........... ma torniamo alla filosofia e questa è giudicata FUD
No. Ma le tue affermazioni purtroppo sono imprecise, e vaghe. Cosa vuol dire "la crittografia si puo' gestire in sw"? Se usi una chiave privata in memorizzata in sw o in un dispositivo hw, la differenza e' solo la maggior sicurezza del secondo caso. "algoritmi altrettanto sicuri del fritz chip", poi, cosa vuol dire?
> > >Ma nel caso dei brevetti software non si è sparso FUD, si è fatta > > >propaganda corretta ed *informazione*. Non mi sembra si stia facendo > > >altrettanto. > > > > bene se quanto ti ho riferito lo ritieni FUD mi spiace, parliamo due > > linguaggi diversi > > Ripeto, le affermazioni vanno circostanziate, specie quando riguardano > fatti tecnici precisi. > quoto, però anche un po' di fiducia si? hai idea del tempo che mi ci è voluto per andare a ripescare tutte le parti che interessavano fra tutte le e-mail e i siti che mi hanno portato alla mia conclusione?
Quale? (ok, ho visto sotto, magari rispondimi in privato)
Ciao, Rob
> Ciao, > Roberto.
e comunque mi è stato detto chiaramente che questa non è la ML in cui discutere di queste cose, quindi mi scuso con chi vorrebbe infrangere la netiquette e proseguire in questo topic, sono disponibile sempre sulla ML servizioemail@xxxxxxxxxxxxxxx e mi scuso con tutti per aver causato 60 e-mail OT. buona serata athos --
Athos Gualazzi http://www.piratpartiet.it -- 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
