Crittografia Asimmetrica - RSA, ECC, Firma Digitale e Code Signing

Cos'e'

#

La crittografia asimmetrica usa una coppia di chiavi matematicamente correlate: una public key (distribuita liberamente) e una private key (mai condivisa). Risolve il problema fondamentale della crittografia simmetrica — come si scambia la chiave segreta su un canale insicuro — senza richiedere un canale separato pre-sicuro. Il prezzo e' la velocita': e' significativamente piu' lenta di AES, quindi viene usata solo per key exchange e firme, mai per cifrare bulk data.

Cifra e firma usando una coppia di chiavi matematicamente correlate. La public key cifra o verifica — la private key decifra o firma. Le due operazioni hanno scopi opposti: confidenzialita' vs autenticazione.

TL;DR

#

Asimmetrica = due chiavi, due operazioni distinte:

1. Cifrare: chiunque cifra con la pub key del destinatario → solo il destinatario (priv key) legge.
2. Firmare: il mittente firma con la propria priv key → chiunque verifica con la pub key del mittente.

La firma non cifra il messaggio — lo autentica. Si firma sempre l'hash del messaggio, mai il testo grezzo. La firma dice: "chi ha la private key ha prodotto questo hash" — e' non-repudiabile.

Regola Fondamentale

#

La regola e' semplice ma i sensi sono opposti. E' la cosa piu' importante di tutta la crittografia asimmetrica — e la piu' frequente fonte di confusione all'esame.

graph LR
    PUB["PUBLIC KEY
    distribuita a tutti"]
    PRIV["PRIVATE KEY
    mai condivisa"]
    CONF["Confidenzialita'
    solo il possessore legge"]
    AUTH["Autenticazione
    firma digitale + non-repudio"]

    PUB -->|cifra| CONF
    PRIV -->|decifra| CONF
    PRIV -->|firma l'hash| AUTH
    PUB -->|verifica la firma| AUTH

Lettura: Due percorsi separati con scopi opposti. Sinistra (confidenzialita'): la public key cifra, solo la private key decifra. Destra (autenticazione): la private key firma l'hash del messaggio, la public key verifica la firma. La stessa coppia di chiavi, usata in direzioni invertite per scopi diversi.

The Raybern Box

#

Gibson usa questa metafora per rendere visivo il principio della crittografia asimmetrica senza matematica. E' uno strumento pratico per ragionare sui casi d'uso e le varianti.

sequenceDiagram
    participant M as Mittente
    participant R as Ricevente

    rect rgba(50, 120, 220, 0.2)
        Note over M,R: VERSIONE 1 - CONFIDENZIALITA'
        R->>M: Cassetta vuota + PUBLIC KEY (chiude ma non apre)
        Note over M: Inserisce il contenuto e chiude con PUBLIC KEY
        M->>R: Cassetta chiusa
        Note over R: Apre con PRIVATE KEY (unica copia)
        Note over M,R: Chi ha copie della pub key non puo' aprire
    end

    rect rgba(50, 180, 80, 0.2)
        Note over M,R: VERSIONE 2 - AUTENTICAZIONE
        Note over M: Inserisce il messaggio e chiude con PRIVATE KEY
        M->>R: Cassetta chiusa con private key
        R->>R: Apre con PUBLIC KEY del mittente
        Note over R: Si apre con pub key = mittente l'ha chiusa = ha firmato
        Note over M,R: Spia apre con pub key ma non puo' richiudere
    end

Lettura: Due scenari della cassetta. Versione 1 (blu): confidenzialita'. Il ricevente manda la cassetta aperta con copie della public key. Il mittente inserisce e chiude. Solo la private key apre. Versione 2 (verde): autenticazione. Il mittente chiude con la propria private key. Chiunque puo' aprire con la public key — ma l'apertura prova chi ha chiuso. Una spia puo' aprire ma non richiudere: il ricevente trova la cassetta aperta e sa che c'e' stata manomissione.

RSA

#

RSA (Rivest-Shamir-Adleman, 1977) e' l'algoritmo asimmetrico storico per eccellenza. La sua sicurezza si basa sulla difficolta' computazionale di fattorizzare il prodotto di due numeri primi molto grandi. Funziona, ma e' piu' lento e richiede chiavi piu' lunghe di ECC per la stessa sicurezza.

ECC — Elliptic Curve Cryptography

#

ECC usa equazioni matematiche su curve ellittiche invece della fattorizzazione di interi. Il vantaggio operativo e' decisivo: chiavi molto piu' corte per la stessa sicurezza, meno CPU, meno banda. ECC sta sostituendo RSA come standard per tutti i nuovi sistemi.

graph LR
    ECC["ECC
    Elliptic Curve Cryptography"]
    ECDHE["ECDHE
    Key exchange TLS 1.3
    Perfect Forward Secrecy"]
    ECDSA["ECDSA
    Digital Signature
    JWT, code signing, certificati"]
    BTC["Bitcoin / Blockchain
    curva secp256k1
    chiavi wallet, firme tx"]
    IOT["Low-power devices
    IoT, smart card
    meno CPU di RSA"]

    ECC --> ECDHE
    ECC --> ECDSA
    ECC --> BTC
    ECC --> IOT

Lettura: La matematica delle curve ellittiche si ramifica in quattro applicazioni distinte. ECDHE: key exchange con PFS in TLS 1.3. ECDSA: firme digitali per JWT, code signing, certificati moderni. Bitcoin: curva secp256k1 per wallet e firme transazioni. Low-power: IoT e smart card dove RSA sarebbe troppo pesante.

Dev parallel: Quando generi un JWT in Node.js o Symfony hai due opzioni comuni — RS256 (RSA 2048, firma 256 byte) o ES256 (ECDSA P-256, firma 64 byte). ES256 usa chiavi piu' piccole, firma piu' veloce, meno CPU per ogni richiesta. Lo impacto diventa visibile ad alto traffico: 10.000 JWT/secondo verifica con RS256 vs ES256 e' facilmente misurabile. Lo stesso principio si vede nelle cipher suite TLS: ECDHE_ECDSA usa key exchange effimero (ECDHE, PFS) e firma del certificato in ECDSA.

Bitcoin usa esattamente ECC — la curva secp256k1. Il tuo indirizzo Bitcoin e' derivato dalla public key ECDSA. Quando firmi una transazione usi la private key ECDSA. E' la stessa matematica del TLS, su una curva diversa scelta per proprieta' algebriche che facilitano l'implementazione hardware ottimizzata.

Chiavi Statiche vs Efimere

#

Nella crittografia asimmetrica coesistono due tipi di chiavi con cicli di vita radicalmente diversi. Le chiavi statiche identificano un'entita' nel tempo. Le chiavi efimere proteggono una singola sessione e poi scompaiono.

Le due chiavi coesistono in TLS 1.3: la chiave statica (nel certificato) autentica il server, le chiavi efimere ECDHE derivano la session key per quella sessione specifica. Perdere la private key statica del server compromette l'identita' — ma non le sessioni passate, protette da PFS.

Code Signing

#

Code signing applica la firma digitale ai binari software. Lo sviluppatore firma il codice con la propria private key prima della distribuzione. Il sistema operativo verifica la firma con la public key del developer (dal certificato) prima di eseguire il binario. Se la firma manca o non torna, il sistema allerta l'utente o blocca l'esecuzione.

Scenario Reale Blue Team

#

La crittografia asimmetrica e' operativa in ogni livello dello stack moderno. Il Blue Team la incontra nell'analisi dei log TLS, nella verifica dei certificati, nell'ispezione dei JWT e nel monitoraggio degli update software.

# Verifica cipher suite ECDHE_ECDSA in uso su un server
openssl s_client -connect api.service.com:443 2>/dev/null \
  | grep -E "Cipher|Group|Protocol"
# Cercare: TLS_AES_256_GCM_SHA384 (TLS 1.3) o ECDHE_ECDSA_* (TLS 1.2)
# ECDHE = PFS attivo; ECDSA = server firmato con ECC

# Controlla algoritmo usato nel certificato del server
openssl s_client -connect api.service.com:443 2>/dev/null \
  | openssl x509 -noout -text \
  | grep -E "Public Key Algorithm|RSA|ECDSA|Signature"
# RSA: chiave statica, piu' grande
# ECDSA: chiave piu' piccola, moderna

# Verifica firma di un eseguibile su Linux con GPG
gpg --verify software.tar.gz.sig software.tar.gz
# Exit code 0 = firma valida; 1 = firma invalida o chiave sconosciuta

# Decodifica un JWT per vedere algoritmo usato
# (header.payload.signature — base64url)
echo "eyJhbGciOiJSUzI1NiJ9" | base64 -d 2>/dev/null
# "alg":"RS256" = RSA; "alg":"ES256" = ECDSA P-256

Collegato a

#

• crypto — categoria
• cryptography — teoria crittografica base: simmetrica, asimmetrica, hashing
• ssl-tls — ECDHE per key exchange e PFS nel TLS handshake
• pki — come la public key viene distribuita via certificati e catena CA