PKI

(Public Key Infrastructure)

“Curs d'Introducció a la criptografia” by Jordi Íñigo Griera is licensed under a
Creative Commons Attribution 4.0 International License.
Project hosted at github.com/jig/crypto

Confiança

les dades es protegeixen amb CIPHER_HASH

$\downarrow$

derivades amb KEA

$\downarrow$

autenticats (els secrets) amb SIGN

$\downarrow$

Claus públiques de servidor i client (opcionalment)
?

Confiança: Claus públiques

hem canviat el problema de

“compartir claus simètriques”

pel de

“compartir claus públiques (asimètriques)”

hem simplificat el problema, però segueix sent massa complex com per a que el solventin els usuaris

com intercanviem les claus públiques (PBK) de forma segura?

Confiança: Claus públiques

ens cal un mapeig segur:

PBK_interlocutor $\rightarrow$ identitat interlocutor

les dades es protegeixen amb CIPHER_HASH

$\downarrow$

derivades amb KEA

$\downarrow$

autenticats (els secrets) amb SIGN

$\downarrow$

Claus públiques de servidor i client

$\downarrow$

identitat interlocutor

Confiança: Claus públiques

PBK_interlocutor $\leftrightarrow$ identitat interlocutor

sistema central de distribució: llista de PBKs compartida
- idea original de Diffie i Hellman el 1976
manualment: ens guardem una llista de PBKs pròpia
- SSH
certificats
- PGP: gestió descentralitzada (Web of trust)
- PKI/X.509: gestió centralitzada

gestió "manual": SSH

el client guarda xifrada la clau privada
el client es guarda en un directori les claus públiques dels servidors en els que confia
el servidor guarda en clar la clau privada (del servei sshd)
el servidor guarda la clau pública vàlida per a cada interlocutor

Gestió amb Certificats

un certificat conté la tupla:

(identitat interlocutor, PBK_interlocutor)

i per a poder-ne verificar la integritat (i l'autenticitat) una tercera part de confiança (TTP) signa aquesta tupla:

PVK_TTP(identitat interlocutor, PBK_interlocutor)

Nota: PVK_TTP(...) significa signatura RSA o ECDSA sobre la cadena "..."

Tercera part de confiança

hem de confiar en PBK_TTP

el propietari de la PVK_TTP corresponent pot ser:

una autoritat central: en una Infraestructura de Clau Pública (PKI)
un "igual": en el model "web of trust" (com en PGP)

Nota:
PGP: Pretty Good Privacy
PKI: Public Key Infrastructure

Encadenat

sovint ni en PGP ni en PKI disposarem localment de la PBK_TTP que ha signat el certificat del nostre interlocutor

però podem "arribar-hi" de forma segura si descarreguem els certificats de les baules intermèdies

PVK_i-1(i, PBK_i) PVK_i-2(i-1, PBK_i-1) $\vdots$ PVK_TTP(1, PBK₁)

PGP

en PGP podem signar les claus de coneguts nosaltres mateixos si ens les han donat de forma segura

...i ells també poden fer el mateix, permetent abastar un pas més

Nota: PGP té una versió de lliure distribució anomenada GPG derivada de la rfc4880 (OpenPGP)

PGP

amb PGP podem arribar a tenir confiança en grups petits o mitjans, però no escala bé a grups grans

cada baula (certificat) té una garantia d'autenticitat $<1$

a partir d'uns quants certificats el nivell de seguretat deixar de ser acceptable

PKI: Infraestructura de clau pública

l'encadenat de certificats el fem a un punt comú

en el cas extrem, tothom pot rebre un certificat d'una única TTP: una autoritat de certificació (CA)

CA única

si rebem una connexió TLS, o rebem un missatge de correu signat, o volem enviar-ne un de xifrat, només ens cal rebre el certificat de l'interlocutor:

PVK_CA(identitat_interlocutor, PBK_interlocutor)

aquest certificat, que el podrem trobar en un repositori qualsevol, i el podrem validar a condició que disposem prèviament la clau PBK_CA
(obtinguda per a medis alternatius fiables)

la PBK_CA és l'únic element que cal distribuir de forma segura, la resta els podrem obtenir de forma no segura i validar-los

CA única: limitacions del model

simple pels clients, però fràgil:

si la CA és compromesa, tot el sistema falla
tots els usuaris han d'estar d'acord en unes mateixes prestacions de seguretat (i mateix cost)

CAs múltiples

els usuaris han d'incorporar una llista de PBK_{CA_i}
- són les CAs arrel (root CA)

els usuaris poden rebre certificats no de les CAs que coneixen els usuaris finals, si no d'entitats intermèdies
- són les CAs subordinades

CAs arrel

les diferents CAs poden especialitzar-se: nivells de seguretat, mètodes de registre, legislación, costos, o simplement diferents organitzacions

els usaris poden escollir en quines CAs arrel confiar i en quines no

l'usuari (...) ha de gestionar
la llista de CAs (arrel) de confiança

CAs subordinades

les CAs subordinades emeten certificats als usuaris

$\Downarrow$

estan en línia o com a mínim, estan actives tot sovint

$\Downarrow$

probabilitat "alta" de compromís de la PVK

$\Downarrow$

hem de poder-les revocar en cas de compromís de la PVK

Jerarquia de CAs: Patró habitual

CA arrel: només emet certificats per a CA subordinades i "revocacions"
- està activa en moments puntuals (fora de línia)
- en cas de compromís no hi ha protocol definit
CA subordinada: emet certificats finalistes (usuaris, servidors)
- està en línia constantment, ja sigui per xarxa pública o privada
- en cas de compromís és segueix el procediment de revocació de CA

Jerarquia de CAs: Patró habitual (ii)

CA arrel: els usuaris (e.g. clients i servidors TLS) tenen instal·lades les CA arrel en que confien
CA subordinada: la reben del seu interlocutor

e.g. quan en una connexió TLS el servidor ens presenta la seva PBK, ens l'aporta certificada per una CA subordinada, juntament amb el certificat de la CA subordinada que l'ha signat:
PVK_CAsub(id-servidor, PBK_servidor)
+ PVK_CAroot(id-CAsub, PBK_CAsub)

la PBK_CAroot l'hem de tenir prèviament instal·lada

RA: Autoritat de Registre

el procediment de registre gestiona la validació de credencials (registre) que demostra que un titular posseeix la clau privada corresponent a la clau pública que presenta

la validació de possessió de la PVK ha de ser automàtica:
- petició de certificació PKCS #10
- certificat autosignat X.509
la validació de la identitat del titular pot ser:
- presencial: per a certificats personals, o amb polítiques de certificació restrictives com els certificats EVC
- en línia, basats en desafiaments sobre el control d'un:
  - compte de correu
  - nom de domini DNS
  - servei web

Certificats X.509

(prèvia)

Base64, DER, ASN.1

Certificats X.509

Estructura serialitzada PVK_CA(interlocutor, PBK_interlocutor)

estructura ASN.1 anomenada Certificate (també X.509)
serialització DER
conversió a caràcters Base64 (opcional)
encapsulat PEM (opcional)

Exemple Certificat Root

(exemple de certificat de google.com)

Format PEM

PEM: Privace Enhanced Mail

principi/final començant per guions i indicant-ne el contingut
(opcional) capçalera detallant-ne el contingut
contingut en base64 (segmentat en línies curtes)

Codificació Base64

Convertim cada 3 bytes en 4 caràcters:

26 lletres majúscules
26 lletres minúscules
10 xifres
+ i /

total: 64 caràcters

i si la cadena no és múltiple de 3 bytes, afegim = al final:

sense = indica que l'últim bloc té tots tres bytes significatius
= indica que l'últim bloc té dos bytes significatius
== indica que l'últim bloc té un byte significatiu

ASN.1: Serialització DER

DER: Distinguished Encoding Rules

funcionalment equivalent a XML, JSON o la serialització nativa de Java $\rightarrow$ tipus lògic convertit a seqüència de bits

DER és independent de l'arquitectura del processador
(endianness, mida dels registres de la CPU)

Codificació TLV: Tipus + Longitud + Valor

ASN.1: Serialització DER

Tipus + Longitud + Valor

TL + V: Valor no estructurat o final (cadena, enter...)
TL + (TL+..., TL+..., ...): valor estructurat (SEQUENCE...)

Experiment: Parser DER en línia: lapo.it

ASN.1: Notació per a definir tipus

ASN.1: Abstract Syntax Notation (One)

equivalent als "esquemes" XML, a les "classes" de Java (que després podem serialitzar), etc.

ASN.1

Tipus bàsics

Numèrics: INTEGER, BOOLEAN, ENUMERATED...
Cadenes: OCTET STRING, BIT STRING, Utf8String, GeneralizedTime...
NULL
OBJECT IDENTIFIER...

ASN.1: OBJECT IDENTIFIER

seqüència única que identifica un concepte, que s'obté
de la ITU-T/CCITT o la ISO

e.g. AESAlgorithmIdentifier ::= 2.16.840.1.101.3.4.0.1

{ joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) modules (0) aes (1) }

ASN.1: Tipus Constructors i Metatipus

SEQUENCE: equivalent a un struct de C/C++
SEQUENCE OF: equivalent a un vector [] de C/C++
SET: com SEQUENCE però sense ordre (semàntica)
SET OF: com SEQUENCE OF però sense ordre (semàntica)
SEQUENCE: equivalent a un struct de C/C++
CHOICE: alternativa de tipus; equivalent a union de C/C++

ASN.1: Certificats X.509 (rfc5280)

exemple d'estructura ASN.1:

Certificate  ::=  SEQUENCE  {
        tbsCertificate       TBSCertificate,
        signatureAlgorithm   AlgorithmIdentifier,
        signatureValue       BIT STRING  }

TBSCertificate  ::=  SEQUENCE  {
        version         [0]  EXPLICIT Version DEFAULT v1,
        serialNumber         CertificateSerialNumber,
        signature            AlgorithmIdentifier,
        issuer               Name,
        validity             Validity,
        subject              Name,
        subjectPublicKeyInfo SubjectPublicKeyInfo,
        issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,
                             -- If present, version MUST be v2 or v3
        subjectUniqueID [2]  IMPLICIT UniqueIdentifier OPTIONAL,
                             -- If present, version MUST be v2 or v3
        extensions      [3]  EXPLICIT Extensions OPTIONAL
                             -- If present, version MUST be v3
        }

Certificats X.509

Certificate

`PVK_CA(interlocutor_x, PBK_{interlocutor_x})`

Certificate  ::=  SEQUENCE  {
        tbsCertificate       TBSCertificate,
        signatureAlgorithm   AlgorithmIdentifier,
        signatureValue       BIT STRING  }

TBSCertificate  ::=  SEQUENCE  {
        version         [0]  EXPLICIT Version DEFAULT v1,
        serialNumber         CertificateSerialNumber,
        signature            AlgorithmIdentifier,
        issuer               Name,
        validity             Validity,
        subject              Name,
        subjectPublicKeyInfo SubjectPublicKeyInfo,
        issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,
                             -- If present, version MUST be v2 or v3
        subjectUniqueID [2]  IMPLICIT UniqueIdentifier OPTIONAL,
                             -- If present, version MUST be v2 or v3
        extensions      [3]  EXPLICIT Extensions OPTIONAL
                             -- If present, version MUST be v3
        }

`Name`

el Name defineix els Distinguished Name o DN

un DN és una seqüència d'RDN (Relative DN)

RDNs habituals:

CN: Common Name (Nom de l'usuari o DNS del servidor)
OU: Organisational Unit (Departament)
O: Organisation (Empresa)
C: Country (Estat)
d'altres: (L) localitat, (ST) estat/província, (DC) domain component...

corresponen a un estructura en arbre (LDAP, X.500)

Altres camps

validity {notBefore, notAfter}
issuer Name
serialNumber INTEGER
extensions SEQUENCE OF {OID, Bool, OCTET STRING}

`extensions SEQUENCE OF {OID, Bool, OCTET STRING}`

és una manera d'afegir informació addicional que no està especificada en el moment de definició de l'estructura X.509
(X.509 versió 3)

hi ha extensions que cal que siguin processades:
es marquen amb Critical True: si un sistema processa el certificat i no entén l'extensió (no en coneix l'OID) ha de rebutjar el certificat

BasicConstraints: cA, pathLenConstraint
KeyUsage
NameConstraints
AuthorityInformationAccess
...

Llista de CAs reconegudes

les CAs reconegudes (arrel) han d'obtenir-se de forma fiable

dins el S.O. i les actualitzacions de l'S.O.
dins el programari que fa servir les claus (navegador, validador de signatures) i les seves actualitzacions

aquest S.O. o el programari actuen de "TTP arrel"

en alguns sistemes es poden modificar aquestes llistes (per part de l'usuari, o l'administrador de sistemes)

Certificats “verds”

Hi ha CAs arrel bones? com gestiono la llista de CAs arrel que haig de fer servir?

el fet que la llista de certificats pugui ser manipulada (usuari, sysadmin) ha fet que apareguin mecanismes "més segurs"

Certificate Transparency: els certificats dels servidors (web) es publiquen en una llista descentralitzada
EV, Extended Validation: les CAs que emeten aquests certificats segueixen una procedimentació específica per la validació de les dades del titular (registre); la llista de certificats arrel normalment està gravada al codi font dels navegadors, etc.
PBK pinning: en aplicacions (no navegadors) podem gravar-hi la PBK_interlocutor que ens interessi; en navegadors puc dir: em crec aquest servidor web

Revocacions

Revocació

els certificats tenen una validesa limitada en el temps, però és possible que el seu contingut deixi de ser vàlid abans

si això passa, cal comunicar-ho a l'RA (Autoritat de Registre) seguint els procediment que dictamini la Política de Certificació (o la Declaració de Pràctiques de Certificació que en depengui)

exemple DNIe: Declaración de prácticas y políticas de certificación

Raons de revocació

keyCompromise: potser he perdut el control de la PVK
affiliationChanged: el DN/SubjectAltName ja no és correcte
superseded: s'ha emès un certificat que el substitueix
cessationOfOperation: ja no cal (e.g. el servidor web ja no existeix)
certificateHold: suspès (posteriorment es cancel·la la suspensió, o es revoca)
privilegeWithdrawn: algun atribut ja no li correspon al titular

Com sabem si un certificat ha estat revocat?

és publica una CRL
és publica en un servidor OCSP

CRL

Certificate Revocation List

és una llista signada (rfc5280) que conté els certicats no caducats que han estat revocats per una CA (o vàries: CRL indirectes), el moment en el que han deixat de ser vàlids, i la raó per la que han deixat de ser vàlids

CRL: observacions

les CRL poden créixer molt: cal ajustar el període de validesa dels certificats emesos
es poden emetre CRL incrementals (delta CRL)
es poden acumular les revocacions de diverses CA en una CRL (CRL indirectes)

ASN.1: CertificateList (rfc5280)

CertificateList  ::=  SEQUENCE  {
    tbsCertList          TBSCertList,
    signatureAlgorithm   AlgorithmIdentifier,
    signatureValue       BIT STRING  }

TBSCertList  ::=  SEQUENCE  {
    version                 Version OPTIONAL,
                                 -- if present, MUST be v2
    signature               AlgorithmIdentifier,
    issuer                  Name,
    thisUpdate              Time,
    nextUpdate              Time OPTIONAL,
    revokedCertificates     SEQUENCE OF SEQUENCE  {
         userCertificate         CertificateSerialNumber,
         revocationDate          Time,
         crlEntryExtensions      Extensions OPTIONAL -- if present, version MUST be v2
    }  OPTIONAL,
    crlExtensions           [0]  EXPLICIT Extensions OPTIONAL -- if present, version MUST be v2
}

Extensions

el mateix format que els certificats, però altres OID

reasonCode
invalidityDate
certificateIssuer (només per a CRL indirectes)

OCSP: On-line Certificate Status Protocol

en CA de gran volum les CRL són inacceptablement grans: OCSP

els servidors OCSP o VA (Validation Authorities) responen l'estat de validesa d'un certificat individual

en servidors web d'alt rendiment,
la VA pot patir una càrrega similar $\rightarrow$ OCSP stapling

Miscel·lània

Cost

gestió de la seguretat de les claus de les entitats finals (usuaris):
procediments de registre, revocació i renovació, personalització Smart Cards, administració de les CA, CRLA, VA, RA...
renovació de claus de la CA (subordinades, roots): les migracions de PKI fins ara han estat massives pel pas de SHA-1 a SHA-2
compromís de clau: hi ha certa probabilitat (assegurança) de que no s'hagin aplicat els procedimnts i mesures tècniques per a protegir les claus
certificats “verds” (contraexemple: CA Let's Encrypt de la fundació ISRG)
Administració de sistemes: distribució de CA pròpies de forma segura
Procediment de registre per a certificació, revocació
complexitat: no/formació...

Time-Stamp Protocol (rfc3161)

les TSA (Time-Stamp Authorities) emeten proves signades de que un conjunt de bytes (hash) ha estat presentat a una hora determinada

és un format de petició i un de resposta que conté un token TimeStampToken (TST):
el token TST es pot presentar com a prova de que un document existia en un cert moment

TSA: Time-Stamp Authority

les TSA s'assemblen a les CA però a banda de disposar d'HSM, tenen una font fiable de temps:
rellotge atòmic, o un rellotge estabilitzat tèrmicament, o connexió GPS, o connexió a un servidor NTP (Stratum-2 o proper), o alguna combinació dels anteriors (habitualment les CA fan servir NTP i prou)

Ús

TLS: autenticació dels extrems de la connexió (e.g. HTTPS)
PKCS #7/CMS: xifrat i sobretot signatura

PKCS #7 / CMS

CMS o Cryptographic Message Standard ens permet xifrar o signar un conjunt de bytes: correu, fitxers individuals, etc.

és una estructura ASN.1:

ContentInfo ::= SEQUENCE {
    contentType ContentType,
    content [0] EXPLICIT ANY DEFINED BY contentType }

ContentType ::= OBJECT IDENTIFIER

PKCS #7 `content`

tipus disponibles:

Data: dades sense tractar
SignedData: dades signades per un o més signants
EnvelopedData: dades xifrades simètricament, i claus xifrades amb la PBK d'un o més receptors
DigestedData: hash (emmagatzament local, o per posterior ensobrat)
EncryptedData: xifrat en cru (emmagatzament local, xifrat simètric)
AuthenticatedData: MAC (emmagatzament local, o en combinació amb ensobrat)

que es poden combinar recursivament: e.g.
SignedData(Data("dades"), [signatures])

PKCS #7: `content`$\rightarrow$`SignedData`

signatura asimètrica

SignedData ::= SEQUENCE {
    version CMSVersion,
    digestAlgorithms DigestAlgorithmIdentifiers,
    encapContentInfo EncapsulatedContentInfo,          -- dades signades
    certificates [0] IMPLICIT CertificateSet OPTIONAL, -- certificats necessaris (CAs sub.)
    crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,  -- CRL necessàries
    signerInfos SignerInfos }                          -- signatura(/es en paral·lel)

DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier

SignerInfos ::= SET OF SignerInfo

PKCS #7: `content`$\rightarrow$`EnvelopedData`

xifrat, simètric o asimètric (ensobrat)

EnvelopedData ::= SEQUENCE {
    version CMSVersion,
    originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
    recipientInfos RecipientInfos,
    encryptedContentInfo EncryptedContentInfo,
    unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL
}

PKCS #7: `content`$\rightarrow$`EnvelopedData + SignedData`

una combinació habitual (e.g. S/MIME) és signar i xifrar

PKCS #7: com a arxiu de certificats

el PKCS #7 es fa servir sovint com a format per a entregar certificats (i CRL)
(e.g. el meu certificat i la cadena de CA):

el PKCS #7 se li dóna amb content SignedData... contenint els certificats i/o les CRL, però sense dades ni signatures

Altres "formats PKCS"

PKCS #7: format ASN.1 signatura, xifrat, arxiu de certificats i CRL
PKCS #11: plantilla C per a llibreries (pkcs11.h) d'HSM
PKCS #1: (només RSA) formats de firma i xifrat; algunes vegades es fa servir com a manera d'identificar el format de clau privada RSA en clar; usat per servidors (TLS)
PKCS #5: procediment per a xifrar bytes a partir d'una contrasenya
PKCS #8: format de clau privada, habitualment xifrat amb
el procediment PKCS #5
PKCS #10: format de petició de certificació, que conté les dades d'identificació (DN), la clau pública, i la signatura per a poder validar-ne la posessió (alternatiu a un X.509 autosignat)
PKCS #12: fitxer xifrat de clau i certificats (usat pels navegadors)

PKI

Confiança

Confiança: Claus públiques

Confiança: Claus públiques

Confiança: Claus públiques

gestió "manual": SSH

Gestió amb Certificats

Tercera part de confiança

Encadenat

PGP

PGP

PKI: Infraestructura de clau pública

CA única

CA única: limitacions del model

CAs múltiples

CAs arrel

CAs subordinades

Jerarquia de CAs: Patró habitual

Jerarquia de CAs: Patró habitual (ii)

RA: Autoritat de Registre

Certificats X.509

Certificats X.509

Exemple Certificat Root

Format PEM

Codificació Base64

ASN.1: Serialització DER

ASN.1: Serialització DER

ASN.1: Notació per a definir tipus

ASN.1

ASN.1: OBJECT IDENTIFIER

ASN.1: Tipus Constructors i Metatipus

ASN.1: Certificats X.509 (rfc5280)

Certificats X.509

PVKCA(interlocutorx, PBKinterlocutorx)

Name

Altres camps

extensionsSEQUENCE OF {OID, Bool, OCTET STRING}

Llista de CAs reconegudes

Certificats “verds”

Revocacions

Revocació

Raons de revocació

Com sabem si un certificat ha estat revocat?

CRL

CRL: observacions

ASN.1: CertificateList (rfc5280)

Extensions

OCSP: On-line Certificate Status Protocol

Miscel·lània

Cost

Time-Stamp Protocol (rfc3161)

TSA: Time-Stamp Authority

Ús

Ús

PKCS #7 / CMS

PKCS #7 content

PKCS #7: content$\rightarrow$SignedData

PKCS #7: content$\rightarrow$EnvelopedData

PKCS #7: content$\rightarrow$EnvelopedData + SignedData

PKCS #7: com a arxiu de certificats

Altres "formats PKCS"

(AdES) $\rightarrow$

`PVK_CA(interlocutor_x, PBK_{interlocutor_x})`

`Name`

`extensions SEQUENCE OF {OID, Bool, OCTET STRING}`

PKCS #7 `content`

PKCS #7: `content`$\rightarrow$`SignedData`

PKCS #7: `content`$\rightarrow$`EnvelopedData`

PKCS #7: `content`$\rightarrow$`EnvelopedData + SignedData`