Perché la crittografia è il cuore della sicurezza
La crittografia (encryption), l’hashing e la Public Key Infrastructure (PKI) sono i tre pilastri tecnologici che traducono in pratica i principi di confidentiality, integrity e non-repudiation. Capire quale strumento serve in ciascuno scenario — e cosa NON garantisce — è esattamente ciò che l’esame CCST Cybersecurity verifica.
Encryption simmetrica vs asimmetrica
L’encryption trasforma il plaintext in ciphertext reversibile con una chiave. Esistono due famiglie:
| Caratteristica | Simmetrica | Asimmetrica |
|---|---|---|
| Chiavi | Una sola chiave condivisa | Coppia public/private |
| Algoritmi | AES (128/192/256 bit), 3DES (legacy) | RSA, ECC, Diffie-Hellman |
| Velocità | Molto veloce | Lenta (calcolo intensivo) |
| Problema chiave | Distribuzione sicura della chiave | Risolve la distribuzione |
| Uso tipico | Bulk data, sessioni | Key exchange, firme digitali |
Il punto chiave: la simmetrica è veloce ma soffre il key distribution problem (come consegno la chiave in modo sicuro?). L’asimmetrica lo risolve perché la public key può circolare liberamente, mentre la private key resta segreta.
Nella realtà si usa un modello ibrido: TLS usa l’asimmetrica solo per negoziare in modo sicuro una session key simmetrica, poi cifra tutto il traffico con AES (veloce). Questo è il funzionamento di HTTPS.
Hashing: integrity, non confidentiality
L’hashing è one-way (non reversibile) e produce un digest di lunghezza fissa. SHA-256 genera sempre un valore di 256 bit (32 byte), indipendentemente dalla dimensione dell’input.
Proprietà fondamentali:
- Deterministico: stesso input → stesso hash.
- Effetto valanga: cambiare un solo bit stravolge il digest.
- Collision resistant: praticamente impossibile trovare due input col medesimo hash.
L’hashing serve a verificare l’integrity (il file/pacchetto non è stato alterato), NON a nascondere i dati. MD5 e SHA-1 sono deprecati per collisioni note: preferire SHA-256 o superiori.
Firme digitali, integrity e non-repudiation
La digital signature combina hashing e crittografia asimmetrica per ottenere integrity + authentication + non-repudiation:
- Il mittente calcola l’hash del messaggio (es. SHA-256).
- Cifra l’hash con la propria private key → firma.
- Il destinatario decifra la firma con la public key del mittente e ricalcola l’hash: se coincidono, il messaggio è integro e proviene davvero da chi possiede quella private key.
La non-repudiation nasce proprio qui: solo il titolare della private key poteva firmare, quindi non può negare di averlo fatto.
Certificati e PKI
Come faccio a fidarmi che una public key appartenga davvero a quel soggetto? Serve una PKI, basata sui certificati digitali X.509 e sulle Certificate Authority (CA).
- La CA firma il certificato del soggetto, legando identità e public key.
- Si forma una chain of trust: Root CA → Intermediate CA → certificato del server.
- La Root CA è pre-installata come trusted nel sistema/browser (trust anchor).
- Revoca: un certificato compromesso viene invalidato via CRL (Certificate Revocation List) o OCSP (verifica in tempo reale).
I tre stati dei dati
La protezione va applicata in base allo stato del dato:
- Data in transit — dati in movimento sulla rete → TLS/SSL, IPsec (VPN), MACsec, SSH.
- Data at rest — dati archiviati su disco/DB → full-disk encryption (LUKS), self-encrypting drives (SED), encryption a livello di file o database.
- Data in use — dati in memoria durante l’elaborazione, lo stato più difficile → secure enclaves, memoria cifrata, controlli di accesso stringenti.
Trappole tipiche d’esame
- Scenario: “Come garantire che un file scaricato non sia stato manomesso?” → Risposta: confrontare un hash SHA-256; è integrity, non confidentiality. L’hashing NON cifra e NON nasconde i dati.
- Scenario: “Serve nascondere il contenuto di un messaggio riservato.” → Risposta: encryption (confidentiality). L’hashing è la scelta sbagliata perché non è reversibile e non protegge la riservatezza.
- Scenario: “Bisogna provare che un documento proviene davvero dal mittente e lui non possa negarlo.” → Risposta: digital signature con la private key del mittente (non-repudiation). Cifrare con la public key del destinatario darebbe solo confidentiality.
- Scenario: “Grande volume di dati da cifrare velocemente in una sessione già stabilita.” → Risposta: crittografia simmetrica (AES); l’asimmetrica è troppo lenta per il bulk e si usa solo per lo scambio della session key.
- Scenario: “Un browser mostra ‘certificato non attendibile’.” → Risposta: la chain of trust è rotta (CA non trusted, certificato scaduto o revocato via CRL/OCSP), non un problema di algoritmo di encryption.