View Full Version : dubbi su SSL
sto lavorando ad un programma sul quale userò connessioni SSL, ma non è questo il punto :P
lavorandoci mi sono tornati vecchi dubbi su SSL (sta storia della crittografia asimmetrica non m'ha mai convinto più di tanto... :mbe: )
in SSL la generazione delle due chiavi asimmetriche si basa su un problema matematico non risolto e che forse non avrà mai soluzione, ovvero la generazione di numeri primi giganteschi. ora, anche ammettendo che le due parti connesse siano in grado di generare tali numeri primi e che il man-in-the-middle non lo sia (cosa che già mi lascia un tantino perplesso), ciò che stavo pensando è che nessuno costringe il man-in-the-middle ad effettuare l'intercettazione a livello Transport, ma potrebbe anche farlo al disopra dell livello SSL.
spiego in termini pratici: A vuole connettersi a B passando per C, e quindi A vuole connettersi tramite SSL in modalità client sapendo che B ascolta in modalità server (cioè B genera le chiavi asimmetriche). C logga tutto quanto avvenga a livello Transport e giustamente di quello che si dicono A e B non capisce una beneamata perché non ha saputo decriptare la chiave simmetrica inviata da A durante l'handshake (non aveva la chiave asimmetrica privata per decriptare). e vabbè.
ora mettiamo invece che C sia un tantinello scafato :D ordine degli eventi:
A chiede a B di connettersi tramite SSL (apre una connessione TCP su una porta sulla quale B ha un server che usa SSL)
C vede ciò e permette ad A di connettersi
B invia a C la chiave pubblica
C col cavolo che la passa ad A: genera altre due chiavi asimmetriche e passa ad A questa seconda chiave pubblica
C elabora una chiave simmetrica sua, la cripta con quella asimmetrica pubblica inviata da B e la manda a B (in sostanza, C stabilisce una connessione SSL con B)
nel frattempo A elabora una chiave simmetrica, la cripta con quella pubblica elaborata da C e la manda a C
C col cavolo che la manda a B :p se la tiene per se' e finge di essere B, stabilisce insomma una connessione SSL con A
C ha stabilito due connessioni SSL, una con A e una con B; la prima in modalità server e la seconda in modalità client.
A manda a C dati criptati pensando di mandarli a B
C se li logga in chiaro e li manda a B sull'altra connessione (li ri-cripta quindi)
ebbene? ho detto un mare di cavolate senza senso o cosa?
grazie per le risposte :)
up!!! e dai su, non vorrete lasciare senza risposta un topic così interessante :D
SSL/TSL non garantisce solo la confidenzialità delle informazioni, ma gestisce anche l'autenticazione (generalmente solo del server).
A si aspetta da B un certificato che C non puo' fornire, per cui il tuo scenario non puo' realizzarsi.
A si aspetta da B un certificato che C non puo' fornire, per cui il tuo scenario non puo' realizzarsi. e perché C non lo può fornire? :wtf:
e perché C non lo può fornire? :wtf:
un certificato (che sia X.509 o OpenPGP è lo stesso) contiene il nome del soggetto a cui è intestato e il nome dell'issuer di quel certificato.
il client A controllerà che all'interno del certificato che l'host a cui intende connettersi (ovvero B) ci sia il nome di B. in caso contrario abortirà la connessione, presumendo che qualcuno stia impersonando B.
perchè il tuo scenario abbia successo C deve essere in grado di fornire un certificato ad A che contiene il nome di B emesso da una certification authority che A considera attendibile e questo non è solitamente possibile.
un certificato (che sia X.509 o OpenPGP è lo stesso) contiene il nome del soggetto a cui è intestato e il nome dell'issuer di quel certificato.
il client A controllerà che all'interno del certificato che l'host a cui intende connettersi (ovvero B) ci sia il nome di B. in caso contrario abortirà la connessione, presumendo che qualcuno stia impersonando B.
perchè il tuo scenario abbia successo C deve essere in grado di fornire un certificato ad A che contiene il nome di B emesso da una certification authority che A considera attendibile e questo non è solitamente possibile. ok, allora diciamo che quando C riceve da B il certificato lo manda anche ad A, ma per il resto le connessioni sono due. ovvero, C stabilisce con A una connessione SSL dandole il certificato ricevuto da B, quindi fingendosi di fatto B. è possibile?
ok, allora diciamo che quando C riceve da B il certificato lo manda anche ad A, ma per il resto le connessioni sono due. ovvero, C stabilisce con A una connessione SSL dandole il certificato ricevuto da B, quindi fingendosi di fatto B. è possibile?
uhm uhm.... no non è possibile perchè C puo' servire ad A il certificato di B (che è pubblico ), ma poi non possedendo la chiave privata corrispondente a quel certificato (che solo B possiede) non è in grado di continuare la comunicazione TLS con A.
per qualche giorno non rispondo sul forum, se non trovi qualcuno iù bravo di me a spiegare ritorniamo poi sull'argomento :fagiano:
uhm uhm.... no non è possibile perchè C puo' servire ad A il certificato di B (che è pubblico ), ma poi non possedendo la chiave privata corrispondente a quel certificato (che solo B possiede) non è in grado di continuare la comunicazione TLS con A. cioè le chiavi asimmetriche sono associate al certificato? quindi sono sempre le stesse??
e il certificato in base a cosa è considerato attendibile dal client? insomma non è possibile produrre un certificato falso che il client consideri attendibile?
per qualche giorno non rispondo sul forum, se non trovi qualcuno iù bravo di me a spiegare ritorniamo poi sull'argomento :fagiano: doh ^^
^TiGeRShArK^
04-01-2007, 14:54
cioè le chiavi asimmetriche sono associate al certificato? quindi sono sempre le stesse??
e il certificato in base a cosa è considerato attendibile dal client? insomma non è possibile produrre un certificato falso che il client consideri attendibile?
doh ^^
no ke non è possibile perchè per firmare il certificato serve la chiave privata del fornitore del servizio, e quindi non può essere in nessun modo falsificato in quanto usando un altra chiave non sarebbe decrittabile usando la chiave pubblica del fornitore del servizio.
che vuol dire "firmare il certificato"? :wtf:
^TiGeRShArK^
04-01-2007, 15:36
che vuol dire "firmare il certificato"? :wtf:
ehm..
nel senso ke x generare il certificato è necessaria la chiave privata di chi lo richiede :fagiano:
ehm..
nel senso ke x generare il certificato è necessaria la chiave privata di chi lo richiede :fagiano: e se io ad A gli rifilo un certificato farlocco come fa a capire che l'ho generato io con la mia chiave privata e non B con la sua visto che la chiave privata di B non la sa? :fagiano:
^TiGeRShArK^
04-01-2007, 16:30
e se io ad A gli rifilo un certificato farlocco come fa a capire che l'ho generato io con la mia chiave privata e non B con la sua visto che la chiave privata di B non la sa? :fagiano:
xkè sa la chiave pubblica di B :D
tu con gli algoritmi asimeetrici puoi ottenere il risultato originale e/o autenticare qualcuno utilizzando la sua chiave pubblica, mentre lui a crittografato e/o firmato tutto con la sua chiave privata :p
è proprio questo il punto di forza della codifica asimmetrica rispetto a quella simmetrica :p
aspetta un attimo, sto certificato viene inviato ad A in forma criptata? non ho mica capito tanto bene... allora, abbiamo detto che per generare un certificato si usa la chiave privata... di preciso a cosa serve la chiave privata nella generazione? si usa per criptare o decriptare il contenuto vero e proprio del certificato stesso? :wtf:
poi mettiamo che quando C riceve il certificato da B lo manda così com'è ad A; come fa A, conoscendo una chiave pubblica (generata da C, ma credendo che appartenga a B) a capire che la chiave privata che ha generato quel certificato non corrisponde alla chiave pubblica che conosce?
poi mettiamo che quando C riceve il certificato da B lo manda così com'è ad A; come fa A, conoscendo una chiave pubblica (generata da C, ma credendo che appartenga a B) a capire che la chiave privata che ha generato quel certificato non corrisponde alla chiave pubblica che conosce? ok, qui mi rispondo da solo: le due chiavi hanno un pezzo in comune, perciò può capirlo. niente falsificazione. ma cosa impedisce piuttosto a C di generare un certificato suo? come mai A è in grado di discriminare il certificato di C da quello di B? in teoria, per quanto ne sa A, C potrebbe tranquillamente essere B, in tutto e per tutto!
EDIT: supponiamo che io, programmatore non malizioso, voglio programmare un redirector SSL. senza intenzione maliziosa, ribadisco: io rappresento un server fidato, però mi è necessario vedere in chiaro i dati inviatimi dal client sulla connessione SSL, e poi devo redirigerli su un'altra connessione SSL al server finale. come mai non è possibile? le due connessioni SSL sono totalmente indipendenti tra loro!!
^TiGeRShArK^
04-01-2007, 19:52
ok, qui mi rispondo da solo: le due chiavi hanno un pezzo in comune, perciò può capirlo. niente falsificazione. ma cosa impedisce piuttosto a C di generare un certificato suo? come mai A è in grado di discriminare il certificato di C da quello di B? in teoria, per quanto ne sa A, C potrebbe tranquillamente essere B, in tutto e per tutto!
EDIT: supponiamo che io, programmatore non malizioso, voglio programmare un redirector SSL. senza intenzione maliziosa, ribadisco: io rappresento un server fidato, però mi è necessario vedere in chiaro i dati inviatimi dal client sulla connessione SSL, e poi devo redirigerli su un'altra connessione SSL al server finale. come mai non è possibile? le due connessioni SSL sono totalmente indipendenti tra loro!!
:fagiano:
ehm..
ma hai capito come funziona la crittografia a chiave asimmetrica almeno ? :D
Le due chiavi non hanno NULLA in comune.
Esse sono semplicemente due fattori primi che moltiplicati danno un numero MOLTO grande.
Esistono degli algoritmi di crittazione e decrittazione basati proprio su questo concetto...
Mettiamo caso ke tu A vuoi inviare qualcosa a B.
In mezzo si mette X a rompere le palle cercando di sostituire il flusso di dati ke gli arriva da A.
Come fa a inviare un flusso di dati congruente a B?
Non può perchè X non conosce la chiave privata di A ma solo la sua chiave pubblica.
Quindi non può in alcun modo generare un flusso di dati ke B scambierà con quello di A in quanto quando B, tramite l'algoritmo di decrittazione, utilizza la chiave pubblica di A vede ke "i conti non gli tornano", ovvero non riuscirà a decrittare correttamente il messaggio.
L'unico modo per X di nuocere è di scoprire la chiave privata di A e quindi codificare il suo flusso di dati applicando all'algoritmo crittografico la chiave privata di A.
spè ke vedo se trovo qualke link col classico esempio di Alice ke non la da a Bob :asd:
^TiGeRShArK^
04-01-2007, 20:02
http://www.networkworld.com/news/64452_05-17-1999.html
http://en.wikipedia.org/wiki/Public-key_cryptography
http://www.aspencrypt.com/crypto101_public.html
Nell'ultimo in particolare viene spiegato il classico attacco di tipo man in the middle ke è quello proposto da te.
E in pratica si dice ke viene impedito dall'autorità 3rd party ke fornisce il certificato :p
EDIT:
però non ho trovato nessun esempio di Alice ke la desse a me... :sob:
:D
aaaaaaaaaaaaaaaaaa ma cioè aspè fateme capì :fagiano:
nella cifratura del certificato le due chiavi vengono usate al contrario... quella pubblica per decriptare e quella privata per criptare :fagiano:
(l'ho capito leggendo il link)
cmq non c'era bisogno che mi spiegassi come funziona la cifratura asimmetrica, almeno quella l'avevo capita :Prrr:
tu invece dovresti ripassarla, visto che non sai come si generano le due chiavi :asd:
le due chiavi non sono di per se' i due numeri primi: i due numeri primi vengono elaborati per generare altri 3 numeri differenti, di cui 1 andrà a far parte di entrambe le chiavi (ed è il pezzo in comune) e gli altri due andranno ciascuno in una chiave. vedo se riesco a ritrovarti su Wikipedia la procedura esatta...
ehm però ancora non capisco... :fagiano:
allora, il certificato inviato da un server che usa SSL contiene un nome codificato da una chiave privata; il client SSL usa la chiave pubblica per decriptare il certificato e così può mostrare all'utente il nome contenuto in esso. se l'utente legge "eBay", o "Paypal", o "QualsiasiAltraFonteOnesta" si tranquillizza e continua la connessione, mentre se legge "HackerCheTiVuoleFormattareIlPCEPeggioAncoraFregartiISoldiDallaCartDiCredito" l'utente rifiuta la connessione :fagiano:
ora io mi sto ancora chiedendo: nel certificato inviato dal man-in-the-middle (criptato con la chiave privata del man-in-the-middle e da decriptare con quella pubblica sempre del man-in-the-middle), chi impedisce al man-in-the-middle di scriverci "NomeDiUnaFonteFidata" anziché "HackerCheTiVuoleEccEcc"??? :fagiano: :fagiano: :fagiano:
beppegrillo
04-01-2007, 21:23
ehm però ancora non capisco... :fagiano:
allora, il certificato inviato da un server che usa SSL contiene un nome codificato da una chiave privata; il client SSL usa la chiave pubblica per decriptare il certificato e così può mostrare all'utente il nome contenuto in esso. se l'utente legge "eBay", o "Paypal", o "QualsiasiAltraFonteOnesta" si tranquillizza e continua la connessione, mentre se legge "HackerCheTiVuoleFormattareIlPCEPeggioAncoraFregartiISoldiDallaCartDiCredito" l'utente rifiuta la connessione :fagiano:
ora io mi sto ancora chiedendo: nel certificato inviato dal man-in-the-middle (criptato con la chiave privata del man-in-the-middle e da decriptare con quella pubblica sempre del man-in-the-middle), chi impedisce al man-in-the-middle di scriverci "NomeDiUnaFonteFidata" anziché "HackerCheTiVuoleEccEcc"??? :fagiano: :fagiano: :fagiano:
Il client non si tranquillizza leggendo il nome "ebay" o simili, ma si tranquillizza quando il certificato, che viene emesso esclusivamente da fonti note
Verisign,Thawte,InstantSSL ecc. ne assicura la corrispondenza ip.
Il client non si tranquillizza leggendo il nome "ebay" o simili, ma si tranquillizza quando il certificato, che viene emesso esclusivamente da fonti note
Verisign,Thawte,InstantSSL ecc. ne assicura la corrispondenza ip. quindi se un server fidato cambia indirizzo IP deve avvisare la CA (Certification Authority)?
trallallero
05-01-2007, 07:34
io no ci ho capito un cazzo :stordita:
quindi se un server fidato cambia indirizzo IP deve avvisare la CA (Certification Authority)?
devi farti rilasciare un altro certificato
devi farti rilasciare un altro certificato capisco; perciò ad ogni connessione è di fatto la CA a confermarti la corrispondenza IP col certificato che hai ricevuto? ad ogni connessione devi anche contattare la CA che ha rilasciato quel certificato, giusto?
capisco; perciò ad ogni connessione è di fatto la CA a confermarti la corrispondenza IP col certificato che hai ricevuto? ad ogni connessione devi anche contattare la CA che ha rilasciato quel certificato, giusto?
usi la sua chiave pubblica
C è l'ente certificante
A si collega a B
B fornisce un certificato ad A. Il certificato è firmato con la chiave privata di C(B ha percio precedentemente richiesto il certificato).
A usa la chiave pubblica di C per verificare che il certificato sia valido.
Dentro al certificato ci puo anche stare criptata la chiave pubblica di B.
B spedisce dati ad A che userà la chiave nel certificato per leggere e spedire i msg.
Percui non è che la contatti ogni volta...la contatti una volta per sapere la chiave pubblica associata a quella CA
usi la sua chiave pubblica
C è l'ente certificante
A si collega a B
B fornisce un certificato ad A. Il certificato è firmato con la chiave privata di C(B ha percio precedentemente richiesto il certificato).
A usa la chiave pubblica di C per verificare che il certificato sia valido.
Dentro al certificato ci puo anche stare criptata la chiave pubblica di B.
B spedisce dati ad A che userà la chiave nel certificato per leggere e spedire i msg.
Percui non è che la contatti ogni volta...la contatti una volta per sapere la chiave pubblica associata a quella CA
Esatto... la lista delle CA di solito la puoi vedere proprio dall'interno del browser. Ad esempio per Firefox si trova in Edit -> Preferences -> Advanced -> Security -> View Certificates -> Authorities
La cosa interessante dell'infrastruttura e' che la chiave privata della CA puo' essere lasciata su di una macchina scollegata dalla rete Internet ed utilizzata solo per la firma iniziale del certificato di B
in pratica c'è un "terzo" che fa da garante?
in pratica c'è un "terzo" che fa da garante?
le CA sono il terzo che fa da garante.
ps. il punto debole di tutto questo meccanismo, sono le CA. O meglio le chiavi private delle CA. Come paliativo si potrebbero usare + chiavi simmetriche di diverse CA, in modo da diminuire le possibilità che un attaker possa mettersi in mezzo ;)
altra cosa, la comunicazione vera e propria se non ricordo male avviene in DES o cmq con crittazione a chiave simmetrica, molto piu efficiente della crittazione assimetrica. Naturalmente la chiave simmetrica viene spedita crittata assimetricamente( :asd: per la frase contorta )
Inanzitutto ringrazio tutti gli utenti del thread, grazie a voi mi sono chiarito molti dubbi. Premetto che a me la questione interessa molto in quanto la mia azienda mi ha chiesto di mettere in piedi un piccolo server in SSL per il collegamento remoto di pochissimi dipendenti ai file aziendali.
Secondo me il punto più debole non è tanto la chiave privata delle CA che probabilmente viene custodita in server non connessi al web e da innumerevoli protezioni fisiche, il punto più debole sta nella chiave privata del server SSL connesso al web, se il man-in-the-middle riesce tramite un attacco a recuperare la chiave privata del server, non gliene frega niente della CA in quanto lascia pure che il server mandi al client il certificato autentico con tanto di firma CA, ma avendo la chiave privata del server, può decriptare la chiave di sessione simmetrica che il client ha crittografato con la chiave pubblica del server e che poi gli ha mandato, a questo punto il server decripta la chiave di sessione simmetrica con la sua chiave privata ma avendola anche il man-in-the-middle a questo punto lui può decriptare tutto quanto e la sicurezza è andata a farsi benedire. :p
E' giusto o mi è sfuggito qualcosa? :stordita:
cut
ma dal momento in cui l'attacker guadagna l'accesso al server in modo da (tra le altre cose possibili) prendere possesso della chiave privata, il problema diventa un'altro :D
infatti...oltre ad aver intercettato tutto il tuo traffico verso il server ti ha pure fottuto il server :p in ogni caso sarà pure una crittografia evoluta tanto che tutte le transazioni finanziarie usano SSL ma in ogni caso l'anello più debole sono le vulnerabilità dei server non i certificatori CA.
Cmq avevo pensato di usare SSL-Explorer, ne ho scoperto la sua esistenza leggendo qui (http://www.tomshw.it/guide.php?guide=20060721), sinceramente ho provato vari tipi di VPN tradizionali ma tutte avevano vari problemi di latenza eccessiva nell'apertura dei file e delle cartelle nonostante avessimo una velocità di upload ottimale. Con questo sistema ho visto che i file e le cartelle si aprono quasi istantaneamente.
Il programma propone di creare un certificato SSL 128bit gratuito self-signed che non è certificato da una CA. altrimenti bisogna spendere 80-100€ all'anno per un certificato firmato.
Leggendo i post precedenti e alla fine dei discorsi si evince che sono le CA a fare da garanti come detto qui (http://www.hwupgrade.it/forum/showpost.php?p=15371784&postcount=17)
Considerando che si è no lo utilizzeranno 3 persone sto programma collegandosi al server mediante un URL del tipo https://87.XXX.XXX.XXX secondo voi ha senso comprare un certificato SSL firmato per 3 persone che lo usano?
In pratica quando ti colleghi al sito firefox ti dice che il certificato potrebbe essere inattendibile o arrivare da fonte non sicura. Ma se scelgo l'opzione di accettare sempre quel certificato nel browser al successivo accesso questa finestra non compare più perchè firefox considera quel determinato certificato attendibile.
Il punto è, se io autorizzo firefox a farmi da garante e ad accettare sempre quel determinato certificato che io sono certo che sia autentico anche se non è firmato da una CA, ha senso spendere 100 e passa € all'anno per comprare un certificato firmato da Verisign & co. che mi fa da garante?
La firma CA mi dà qualche sicurezza concreta in più?
A questo punto se viene il mad-in-the-middle e genera un falso certificato self-signed usando le stesse informazioni che ho usato io per crearlo, firefox si accorge che non è lo stesso che gli ho fatto salvare io, avvertendomi del pericolo o lo accetta permettendo così al man-in-the-middle di fare il suo sporco lavoro?
:muro: :D
Il punto è, se io autorizzo firefox a farmi da garante e ad accettare sempre quel determinato certificato che io sono certo che sia autentico anche se non è firmato da una CA, ha senso spendere 100 e passa € all'anno per comprare un certificato firmato da Verisign & co. che mi fa da garante? cacert.org fornisce certificati gratis.
www.cacert.org
in SSL la generazione delle due chiavi asimmetriche si basa su un problema matematico non risolto e che forse non avrà mai soluzione, ovvero la generazione di numeri primi giganteschi.
Umh...no. Il problema è la fattorizzazione di numeri grandi, non trovare numeri primi grandi. E presumo tu stia parlando di RSA. Altri metodi (tipo ElGamal) si basano su altri problemi.
Cmq era solo per fare una precisazione fastidiosa...
CAcert nonostante sia gratuito non è che mi ispiri molta fiducia....a partire dal fatto che almeno per ora non è una CA autorizzata nè in firefox nè in internet explorer.
In ogni caso il dubbio di prima resta....
Il punto è, se io autorizzo firefox a farmi da garante e ad accettare sempre quel determinato certificato che io sono certo che sia autentico anche se non è firmato da una CA, ha senso spendere 100 e passa € all'anno per comprare un certificato firmato da Verisign & co. che mi fa da garante?
La firma CA mi dà qualche sicurezza concreta in più?
A questo punto se viene il mad-in-the-middle e genera un falso certificato self-signed usando le stesse informazioni che ho usato io per crearlo, firefox si accorge che non è lo stesso che gli ho fatto salvare io, avvertendomi del pericolo o lo accetta permettendo così al man-in-the-middle di fare il suo sporco lavoro?
:muro: :D
se il man-in-the-middle riesce tramite un attacco a recuperare la chiave privata del server, non gliene frega niente della CA in quanto lascia pure che il server mandi al client il certificato autentico con tanto di firma CA, ma avendo la chiave privata del server, può decriptare la chiave di sessione simmetrica che il client ha crittografato con la chiave pubblica del server e che poi gli ha mandato, a questo punto il server decripta la chiave di sessione simmetrica con la sua chiave privata ma avendola anche il man-in-the-middle a questo punto lui può decriptare tutto quanto e la sicurezza è andata a farsi benedire.
E' giusto o mi è sfuggito qualcosa? :stordita:
la chiave privata del server ssl non viaggia sul canale, per cui non puo' essere intercettata da un attaccante. Puo' essere "rubata" se ti bucano la macchina, ma a quel punto :help:
il problema di un man in the middle è se l'attaccante ha modo di produrre un certificato che il tuo browser accetta perchè emesso da una CA di fiducia, ma in teoria se la CA è attendibile ciò non si dovrebbe verificare.
se i client che devi far connettere fanno parte della tua organizzazione non hai necessariamente bisogno di una CA esterna ma con una CA privata ottieni la medesima sicurezza.
L'ente certificatore è necessario quando ci si connette a un server che non si ha la possibiilità di certificare di persona (nel tuo caso prendendo il certificato dal sysadmin della nostra azienda).
ma dal momento in cui l'attacker guadagna l'accesso al server in modo da (tra le altre cose possibili) prendere possesso della chiave privata, il problema diventa un'altro :D
la chiave privata del server ssl non viaggia sul canale, per cui non puo' essere intercettata da un attaccante. Puo' essere "rubata" se ti bucano la macchina, ma a quel punto :help:
Forse si potrebbe risolvere (parzialmente) mettendo la chiave privata in una scatolotta esterna, tipo smart card, che esegue solo l'operazione di decodifica, codifica e firma in base alla chiave, ma non la restituisce mai, proprio come si fa con le smart card: infatti se non erro è proprio così che sono usate, per esempio per l'identificazione. Così, anche se il server venisse violato, almeno la chiave non verrebbe perduta: cioè potrebbero decodificare tutto quello che vogliono, finchè hanno il controllo della macchina, ma non tutto quello che è stato codificato da quando la chiave esiste, come accadrebbe se venissero in possesso della chiave, che sarebbe molto più grave.
Forse si potrebbe risolvere (parzialmente) mettendo la chiave privata in una scatolotta esterna, tipo smart card, che esegue solo l'operazione di decodifica, codifica e firma in base alla chiave, ma non la restituisce mai, proprio come si fa con le smart card: infatti se non erro è proprio così che sono usate, per esempio per l'identificazione. Così, anche se il server venisse violato, almeno la chiave non verrebbe perduta: cioè potrebbero decodificare tutto quello che vogliono, finchè hanno il controllo della macchina, ma non tutto quello che è stato codificato da quando la chiave esiste, come accadrebbe se venissero in possesso della chiave, che sarebbe molto più grave.
questi dispositivi esistono ma hanno un costo molto elevato, tanto che non si trovano sui server web ma generalmente sulle macchine che ospitano le autorità di certificazione per proteggere le chiavi.
questi dispositivi esistono ma hanno un costo molto elevato, tanto che non si trovano sui server web ma generalmente sulle macchine che ospitano le autorità di certificazione per proteggere le chiavi.
Davvero? :stordita: Eppure io credevo veramente che fosse tecnicamente molto semplice... ora che mi ci fai pensare però, si tratta di devices che devo effettuare un numero elevato di operazioni di codifica/decodifica, niente affatto semplici o "leggere", ben diverso dal caso del chip di una SmartCard, che nella peggiore delle ipotesi deve firmare un documento al minuto o giù di lì... :fagiano:
Davvero? :stordita: Eppure io credevo veramente che fosse tecnicamente molto semplice... ora che mi ci fai pensare però, si tratta di devices che devo effettuare un numero elevato di operazioni di codifica/decodifica, niente affatto semplici o "leggere", ben diverso dal caso del chip di una SmartCard, che nella peggiore delle ipotesi deve firmare un documento al minuto o giù di lì... :fagiano:
la difficoltà principale è assicurare che non siano alterabili o leggibili in alcun modo.
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.