trust anchor come elementi che mi vanno a dare chiavi pubbliche che so essere sicure. Posso andare a identificare 3 tipi macroscopici:
Il paradigma tofu identifica i protocolli in cui presupponiamo di non essere sotto attacco la prima volta che interagiamo con una entità. Immaginiamo la situazione di una connessione ssh. Praticamente presupponiamo che non stiamo subendo un mit e non dovremmo ricevere una chiave pubblica falsa. Praticmente questo è key distribution su un canale in cui eseguiamo il protocollo stesso. Assumiamo che non ci siano attacchi attivi e che alla fine anche se ci fossero sarebbero passivi. Tofu spesso si mischia ad un approccio out of band, in cui la chiave pubblica la passo su un canale diverso da quello che uso per le comunicazioni. Potrebbe essere una verifica per esempio tramite una telefonata banalmente. Molto utili quando ho un secondo canale utilizzabile. Una situazione potrebbe essere quella per abilitare per esempio un nuovo dispositivo con telegram e whatsapp. Per quel che concerne gli approcci delegati mi trovo in situazioni in cui sto cercando di andare a sfruttare entità terza per occuparmi delle chiavi pubbliche che vado a distribuire. Del tipo: Alice e Bob non si conoscono ma conoscono un terzo, immaginiamo Carl. In questo approccio Alice e Bob delegano Carl nel comunicare loro la chiave con cui andare a comunicare. Carl è una trust anchor di Alice e Bob e tecnicamente il fatto che si fidino si concretizza con la memorizzazione della chiave pubblica di Carl. Questo approccio di avere un ente, che distribuisce le chiavi, possiamo anche definirlo come decentralizzato.
Distribuire chiavi pubbliche random ovviamente non è sufficiente e sarebbe il caso invece andare a a gestire tutto un aspetto legato ai metadati, che siano valori tecnici o meno. Spesso non servono al protocollo di per sé, ma sono molto comodi per alcuni scopi. Dare delle chiavi senza associarle a dati aggiunti che diano anche dei limiti temporali di utilizzo, per esempio, è molto rischioso.
In generale troviamo delle attestazioni crittografiche che certificano la bontà di una chiave. Spesso le chiavi sono accompagnate da questi documenti di verifica per una questione di sicurezza.
Se vogliamo andare a specializzarci in ambito web è sicuramente lo standard X509. Nome dello standard che usiamo per verificare dei certificati nell’ambito del web. In questo troviamo nomi del tipo: distinguished name → chi è il proprietario di questo certificato, common name → dominio su cui usare questo certificato, informazioni sull’identità legale. Questo vuol creare un legame forte da un chiave pubblica e distinguished name. In più abbiamo anche altri metadati che abbiamo prima.
Troviamo anche spesso informazioni riguardo lo scopo specifico di un determinato certificato. Concettualmente abbiamo queste informazioni e per dare qualche informazioni tecnica diciamo che X509 è un concetto astratto che ci dice che cosa possiamo mettere dentro quello che ci inventiamo e come altro standard è ASN.1
Approfondisci argomento standard DER e PEM, in cui abbiamo un contenuto informativo scritto in modi diversi. PEM è la codifica in base 64 di un file DEM. Un file PEM include più blocchi codificati DER con dei tag che aiutano a capire che ci sia effettivamente su questi blocchi.
PEM definisce questo formato, ma un’altra cosa sono le estensioni dei file in cui sono codificati queste informazioni: .key, .pub, .crt, .csr, .crl Praticamente sono delle estensioni che sono concretamente dei formati pem. Alla fine DEM e PEM sono formati usati per il certificato x509v3, ma anche in altre situazioni per memorizzare informazioni relativi a certificati web.