M7 - Infraest Clau Pub

Infraestructura de clau pblica
PKI
Helena Rif Pous
P03/05024/02265
Universitat Oberta de Catalunya P03/05024/02265
ndex
Introducci .......................................................................................... Objectius ............................................................................................... 1. Conceptes bsics ............................................................................ 1.1. Problemtica de la distribuci de claus ...................................... 1.2. Propsits duna infraestructura de clau pblica (PKI) ................ 1.3. Estndards dinfraestructura de clau pblica ............................. 2. Components duna infraestructura de clau pblica ........... 2.1. Autoritat de certificaci .............................................................. 2.2. Autoritat de registre .................................................................... 2.3. Subscriptors i entitats finals ....................................................... 2.4. Usuaris ........................................................................................ 2.5. Repositoris .................................................................................. 2.6. Autoritat de validaci ................................................................. 2.6.1. Online certificate status protocol (OCSP) ............................ 2.6.2. Simple certificate validation protocol (SCVP) ...................... 2.7. Autoritat de segellat de temps .................................................... 3. Models de confiana ..................................................................... 3.1. El model distribut ...................................................................... 3.2. El model pla ................................................................................ 3.3. El model jerrquic ....................................................................... 3.4. El model de navegaci per llista de confiana ........................... 3.5. El model de certificats creuats .................................................... 3.6. El model Bridge-CA .................................................................... 4. Cicle de vida de claus i certificats digitals ............................. 4.1. Generaci del parell de claus ...................................................... 4.2. Registre ........................................................................................ 4.3. Certificaci .................................................................................. 4.4. Recuperaci de claus ................................................................... 4.5. Revocaci de certificats ............................................................... 4.6. Renovaci de certificats .............................................................. 5. Estructures de dades bsiques de PKIX ................................... 5.1. Certificats X.509 ......................................................................... 5.1.1. Nom dels components dun certificat ............................ 5.1.2. Estructura dun certificat ................................................. 5.2. Llistes de revocaci (CRL) ...........................................................
5 6 7 7 8 8 10 10 11 11 12 12 13 14 14 15 16 16 18 18 19 20 21 23 23 24 24 25 25 26 28 28 28 29 32
5.2.1. Tipus de llistes de revocaci de certificats ...................... 5.2.2. Punts de distribuci de llistes de revocaci de certificats .................................................................... 5.2.3. Format de les llistes de revocaci de certificats .............. 6. Format i procediments per a generar missatges: PKCS ....... 6.1. El PKCS#7 ................................................................................... 6.1.1. Els data ............................................................................ 6.1.2. Els signedData .................................................................. 6.1.3. Els envelopedData ............................................................. 6.1.4. Els signedAndEnvelopedData ............................................. 6.1.5. Els digestedData ................................................................ 6.1.6. Els encryptedData ............................................................. 6.2. El PKCS#10 ................................................................................. 6.3. El PKCS#12 ................................................................................. 7. Protocols que utilitzen infraestructura de clau pblica ............................................................................... 7.1. IPsec ............................................................................................ 7.2. SSL ............................................................................................... 7.3. S/MIME ....................................................................................... 7.4. Seguretat en XML ....................................................................... Resum .................................................................................................... Activitats .............................................................................................. Exercicis dautoavaluaci ................................................................ Solucionari ........................................................................................... Glossari ................................................................................................. Bibliografia ..........................................................................................
33 34 34 37 38 38 38 40 41 43 43 44 45
47 47 48 49 49 51 53 53 54 55 56
Introducci
En aquest mdul estudiarem de quina manera s possible implantar sistemes criptogrfics basats en clau pblica que permetin ls generalitzat de serveis dintegritat, confidencialitat, autenticitat i no-repudi. En primer lloc, veurem quina s la problemtica associada a la implementaci de la criptografia asimtrica, i presentarem la soluci de la infraestructura de clau pblica (o PKI, public key infrastructure). La tecnologia dinfraestructura de clau pblica est en fase de desenvolupament. Hi participen moltes institucions i grups dusuaris, i el procs destandarditzaci no s fcil ni rpid. En aquest mdul no pretenem veure totes les possibilitats duna infraestructura de clau pblica, sin noms donar una idea general de la tecnologia. Nestudiarem els components essencials, en especial el certificat digital X509, i veurem com sinterrelacionen per a crear els diferents models de PKI. Daquesta manera, obtindrem una visi global dels passos que calen per a poder oferir serveis de criptografia de clau pblica a un conjunt dusuaris. Un cop coneguts els principis duna infraestructura de clau pblica, veurem de quina manera s possible generar missatges segurs entre diferents aplicacions dacord amb els estndards actuals. Finalment, veurem alguns dels protocols i serveis de seguretat actuals ms coneguts, que es fonamenten en infraestructures de clau pblica per al seu correcte funcionament.
Objectius
Els materials didctics daquest mdul us permetran assolir els objectius segents: 1. Entendre els principis bsics duna infraestructura de clau pblica: els problemes que resol, els seus components i les seves funcions. 2. Assimilar les caracterstiques de les estructures bsiques que sutilitzen dins un entorn dinfraestructura de clau pblica, quina mena dinformaci contenen i per a qu serveixen. 3. Comprendre el format de les estructures de dades PKCS ms importants emprades en criptografia de clau pblica. 4. Conixer el funcionament de diversos protocols de seguretat que es basen en la tecnologia dinfraestructura de clau pblica.
1. Conceptes bsics
En aquest apartat veurem quines sn les motivacions del naixement de les infraestructures de clau pblica.
1.1. Problemtica de la distribuci de claus La criptografia de clau pblica permet lintercanvi de missatges confidencials i ntegres de manera gil, sempre que disposem de la clau pblica de linterlocutor amb qui ens comuniquem. El problema s com obtenir aquesta clau pblica i poder estar segurs que pertany a qui ens pensem. Les claus pbliques sn justament aix: pbliques; i un intrs prou hbil podria tenir accs al directori on estan ubicades i substituir la clau pblica dalgun usuari per la seva prpia. Daquesta manera, els interlocutors que utilitzessin la clau pensarien que sestan comunicant amb aquell usuari quan, en realitat, ho farien amb lintrs. s el que es coneix com atac de lhome a mig cam. Diffie i Hellman (1976) van pensar que el maldecap de la distribuci de claus es resoldria amb un directori segur en lnia en el qual sestabls de manera unvoca el lligam entre un nom distintiu dusuari i una clau pblica. El directori pblic hauria de signar totes les seves transaccions de manera que ning no en pogus suplantar la identitat. El problema raa en el baix rendiment que el sistema oferia en poblacions dusuaris mitjanes o grans. L. Kohnfelder (1978) es va basar en la idea duna autoritat central de confiana introduda per Diffie i Hellman i va proposar crear uns registres de dades signades els certificats que permetrien que la distribuci de claus es fes des de directoris pblics que no requerissin confiana.
Vegeu els criptosistemes de clau pblica en el mdul Xifres de clau pblica daquesta assignatura.
Un certificat digital s una estructura de dades que cont informaci del propietari de les claus criptogrfiques, la clau pblica en si i una signatura digital dels dos camps anteriors que hi dna validesa.
La signatura, realitzada per un usuari o entitat externa lleial, assegura la integritat contra una possible modificaci no desitjada de les dades. La confiana en el signatari sestn al subjecte del certificat.
Daleshores en, els certificats han esdevingut el principal mitj de distribuci de les claus pbliques dels sistemes de clau asimtrica. De tota manera, ls de certificats no resol totalment el problema de la distribuci de claus, sin que la trasllada a un nivell superior. Qui ha de signar el certificat? Quins mecanismes sn necessaris perqu dos usuaris que no es coneixen puguin assegurar la seva identitat en una comunicaci virtual? En definitiva, quin s el model de confiana?
En lapartat 3 daquest mdul veurem els models de confiana ms comuns i qu ofereix cadascun.
1.2. Propsits duna infraestructura de clau pblica (PKI) Lobjectiu duna infraestructura de clau pblica s la gesti eficient i confiable de les claus criptogrfiques i els certificats perqu es puguin utilitzar per a funcions dautenticaci, integritat, no-repudi i confidencialitat. La infraestructura de clau pblica crea un marc segur dintercanvi de dades en un entorn tpicament insegur com Internet.
Una infraestructura de clau pblica* (PKI) s el conjunt de maquinari, programari, persones, poltiques i procediments necessaris per a crear i gestionar certificats digitals basats en criptografia de clau pblica.
* En angls, public key infrastructure.
El certificat s lelement central de la infraestructura de clau pblica al voltant del qual es crea aquesta infraestructura de suport que abraa serveis com el registre dusuaris, lemissi de certificats, la seva distribuci des de directoris pblics, la seva renovaci i revocaci, la recuperaci de claus, etc.
1.3. Estndards dinfraestructura de clau pblica Per a poder tenir aplicacions interoperables, cal establir uns estndards en matria dinfraestructura de clau pblica. El fet que diversos fabricants es posin dacord en la sintaxi i lestructura de les dades atreu tant desenvolupadors com usuaris finals, i fa que el mercat creixi i millori. El mercat de la seguretat es troba a mig cam de la transici entre solucions propietries i estndards oberts. Alguns fabricants no volen donar a conixer les seves solucions perqu basen la seguretat en lobscuritat i el secret; aquesta no s una bona poltica, ja que no compleix la suposici de Kerckhoff. Els principals organismes estandarditzadors en matria dinfraestructura de clau pblica a Internet sn els segents: a) Internet Engineering Task Force (IETF). La IETF, com a frum global per al desenvolupament destndards de xarxes, s el lloc preferent per al desenvolupament despecificacions i estndards que ofereixin suport al creixement
Vegeu la suposici de Kerckhoff en el subapartat 4.1 del mdul Fonaments de criptografia daquesta assignatura.
de les aplicacions de serveis de confiana. El treball fet en el camp de les infraestructures de clau pblica dins del grup anomenat PKIX s un exemple daquesta activitat, ja que s el model ms mpliament acceptat i en el qual ens basarem en aquest mdul. El mitj de publicaci dels estndards i la informaci relacionada s la srie de documents anomenats requests for comments (RFC), dels quals nhi ha dues categories principals: Els standards track sn aquells que segueixen el progrs de lRFC des de la proposta o esborrany fins a lestndard. Els non-standards track no tenen laprovaci i el consens de tota la comunitat Internet i es classifiquen en experimentals, informatius i histrics. b) International Standards Organisation (ISO). LISO es focalitza en la ratificaci destndards generats tant per la IETF com per altres organismes nacionals per tal dapropar ms determinades normes a la indstria. c) European Telecommunications Standards Institute (ETSI). LETSI s un organisme europeu format per empreses actives en la indstria de telecomunicacions, principalment com a provedors de serveis i venedors. d) European Committee for Standardisation (CEN). El CEN comprn els organismes destandarditzaci nacionals dEuropa. Per altra banda, els RSA Laboratories han fet importants aportacions en els formats de dades basades en infraestructura de clau pblica i han aconseguit que moltes de les seves especificacions shagin convertit en estndards de facto, com els PKCS.
Veurem alguns exemples de PKCS en lapartat 6 daquest mdul.
10
2. Components duna infraestructura de clau pblica
En aquest apartat veurem els components duna infraestructura de clau pblica tpica. Malgrat que els components essencials sn lautoritat de certificaci, els subscriptors i els repositoris, nhem afegit daltres com lautoritat de registre, lautoritat de validaci o lautoritat de segellat de temps, que donen una visi completa de les funcions que pot arribar a proporcionar una infraestructura de clau pblica. Altres components opcionals que no detallarem sn el repositori de claus (que permet donar serveis de recuperaci de claus criptogrfiques) o lautoritat documental.
2.1. Autoritat de certificaci
Lautoritat de certificaci* (CA) s la responsable demetre i revocar certificats. s lentitat de confiana que dna legitimitat a la relaci duna clau pblica amb la identitat dun usuari o servei.
* En angls, certification authority.
Poltiques de certificat i prctiques de certificaci La relaci legal i tcnica entre una autoritat de certificaci i els seus subscriptors i usuaris est regida per les poltiques de certificats (certificate policy, CP) i la declaraci de prctiques de certificaci (certification practice statement, CPS). Una poltica de certificat exposa la garantia de seguretat que es pot donar al certificat i els usos per als quals s adequat. s un concepte general, no particular duna organitzaci. Serveix com a vehicle per a establir les bases de la interoperabilitat. Les prctiques de certificaci estipulen la manera com una autoritat de certificaci en particular estableix aquesta garantia de seguretat. Normalment, la CPS se sol presentar en forma de document a labast del pblic.
Una infraestructura de clau pblica pot tenir una o ms autoritats de certificaci. La creaci duna autoritat de certificaci comena amb la generaci del parell de claus (pblica i privada) que sutilitzaran per a signar i validar els certificats digitals que emeti lautoritat de certificaci. Les claus han de ser prou fortes perqu la probabilitat que un atacant les trenqui sigui extramadament durant el temps de vida dels certificats que shi signaran. Aix dependr de la combinaci de la longitud de la clau i la qualitat de lalgorisme de generaci de claus.
La relaci entre les diferents autoritats de certificaci es descriu en lapartat 3 daquest mdul.
Un cop generat el parell de claus, la clau pblica sha de distribuir duna manera segura a totes les entitats de confiana potencials. Aquesta distribuci es pot fer tant per mitj dun certificat digital ems per una autoritat de certificaci en la qual els usuaris ja confien, o via un certificat generat per la prpia autoritat de certificaci que sacabi de crear (aquest tipus de certificats reben el nom de certificats autosignats). Per a garantir la seguretat de la transmissi,
11
aquests certificats digitals de les autoritats de certificaci shauran de distribuir des dun canal fora de banda (caldr passar el certificat fsicament, per correu, incorporat en el programari, etc.). Lautoritat de certificaci tamb ha de protegir la seva clau privada dun s no autoritzat. La seguretat duna infraestructura de clau pblica depn de les bones prctiques que sutilitzin per a crear i gestionar tota la infraestructura de confiana. s important que el control daccs a les claus de lautoritat de certificaci sigui molt estricte; per aix, generalment les claus es guarden en una targeta o maquinari criptogrfic i es fa s de la protecci fsica que representa tenir lautoritat de certificaci allada i sense cap connexi de xarxa.
Els dispositius ms emprat Els dispositius criptogrfics ms utilitzats sn les targetes intelligents (smartcards), HSM (hardware security modules) i tokens USB.
El nucli bsic duna autoritat de certificaci s el parell de claus criptogrfiques. Per a ms de les claus, les autoritats de certificaci acostumen a estar formades per diversos subcomponents o serveis, com el repositori de certificats, el repositori de claus, serveis segurs de logs, etc.
2.2. Autoritat de registre
Lautoritat de registre* (RA) s lencarregada de verificar el lligam entre les claus pbliques i la identitat dels seus titulars.
* En angls, registration authority.
A lEstat espanyol A lEstat espanyol, les autoritats de registre de la Fbrica Nacional de Moneda i Timbre sn les delegacions i administracions que lAgncia Tributria t en cada localitat, i les oficines consulars.
Les autoritats de registre sn un component opcional duna infraestructura de clau pblica que sutilitza per a descarregar lautoritat de certificaci de moltes de les funcions administratives. En particular, sn especialment tils en organitzacions grans i geogrficament disperses.
Poca seguretat Quan el model de dinfraestructura de clau pblica no requereix un nivell de seguretat gaire elevat, lautoritat de registre es pot automatitzar de manera que la validaci sigui ms laxa i sefectu ms mecnicament.
2.3. Subscriptors i entitats finals
Els subscriptors i les entitats finals sn aquells que posseeixen un parell de claus (pblica i privada) i un certificat associat a la clau pblica.
Amb aquest parell de claus podran efectuar signatures digitals i xifrar i desxifrar documents. Una entitat final representa un organisme, mentre que un subscriptor s una persona.
12
2.4. Usuaris
Els usuaris sn els agents que validen signatures digitals i la seva ruta de certificaci a partir de claus pbliques emeses per autoritats de certificaci de confiana. Tamb poden xifrar documents per a subscriptors i entitats finals.
Observeu que, a diferncia dels subscriptors i les entitats finals duna infraestructura de clau pblica, els usuaris no tenen per qu tenir cap parell de claus ni cap certificat. Evidentment, subscriptors i entitats finals sn, en particular, usuaris.
2.5. Repositoris
Els repositoris sn les estructures encarregades demmagatzemar la informaci relativa a la infraestructura de clau pblica. Els dos repositoris ms importants en una infraestructura de clau pblica sn el repositori de certificats i el repositori de llistes de revocaci de certificats. Una llista de revocaci de certificats* (CRL) inclou tots aquells certificats que per diversos motius sn invlids abans de la data de caducitat establerta en el mateix certificat.
* En angls, certification revocation list.
El tipus de repositoris ms utilitzats en infraestructura de clau pblica sn els directoris. Un directori s una base de dades especialitzada en la qual semmagatzema informaci tipificada i organitzada sobre objectes. Est optimitzat per als accessos de lectura, les navegacions i les grans cerques, i el seu objectiu s donar respostes rpides a un alt volum de peticions. LX.500 s un directori basat en larquitectura OSI i dissenyat sota els auspicis de lISI i altres organitzacions destandarditzaci internacionals. En el model X.500, la informaci est organitzada de manera jerrquica (estructura tpica darbre) i cada node cont objectes duna classe determinada amb diferents atributs que sn els que realment contenen la informaci.
13
Les entrades al directori estan disposades en un arbre i utilitzen el subconjunt datributs anomenat nom distingit* (DN). La situaci de lentrada anterior en larbre X.500 seria:
* En angls, distinguished name.
Per a accedir als directoris X.500 es defin el protocol daccs al directori* (DAP). Per el DAP era un protocol del llegat ISO i tenia el defecte que no era compatible amb el protocol dInternet TCP/IP. La IETF (1995) va afegir a la seva lnia de treball el desenvolupament dun protocol que utilitzs un model de dades X.500, per que funcions sobre TCP/IP i que fos ms fcil dimplementar i de posar en marxa. Es va anomenar LDAP (lightweight directory access protocol) i el desembre de 1997 en van treure la versi 2 com a proposta destndard Internet.
LDAP LLDAP va ser originriament desenvolupat a la Universitat de Michigan.
* En angls, directory access protocol.
2.6. Autoritat de validaci
Lautoritat de validaci* (VA) s lencarregada de comprovar la validesa dels certificats digitals.
* En angls, validation authority.
Aquesta autoritat pot ser la prpia autoritat de certificaci o una entitat externa. Els protocols de validaci de certificats sn mecanismes que proporcionen informaci sobre lestat actual del certificat (revocat, susps, vlid o estat desconegut) o relativa a la cadena de certificaci necessria per a validar lautenticitat del certificat. Una de les principals deficincies de les llistes de revocaci de certificats s que la periodicitat amb qu es publiquen les renovacions no est sota el control de les aplicacions que han de validar els certificats. Idealment, el coneixement sobre si un certificat est revocat o no, hauria dobtenir-se en el mateix moment en qu es vol utilitzar. Hi ha diversos protocols de verificaci en lnia per a obtenir respostes instantnies sobre lestat dels certificats implicats.
14
A continuaci analitzarem dos protocols per a validar certificats: lOCSP (online certificate status protocol) i lSCVP (simple certificate validation protocol).
2.6.1. Online certificate status protocol (OCSP)
Lonline certificate status protocol (OCSP) s un protocol client/servidor que valida lestat dels certificats sol licitats i retorna una resposta signada digitalment.
El servidor, implementat en lautoritat de validaci, connecta amb les autoritats de certificaci apropiades o per algun altre mecanisme de confiana, i obt les dades de lestat dels certificats a partir de llistes de revocaci de certificats. Lautoritat de validaci es fa responsable de les respostes que envia als seus clients (per aix les signa), i els clients confien en lautoritat de validaci i naccepten la sentncia.
LOCSP ofereix dues millores respecte a la validaci de certificats a partir de llistes de revocaci de certificats:
1) Gesti eficient dels riscos: lautoritat de validaci pot respondre a lusuari amb informaci en temps real.
2) Reducci del trnsit generat: els usuaris no reben grans llistes de certificats de les quals noms els interessa una entrada, sin noms la informaci que necessiten. Per a assegurar la mxima compatibilitat entre xarxes, es fa servir lHTTP com a protocol de transport de les peticions OCSP.
2.6.2. Simple certificate validation protocol (SCVP)
SCVP s una lnia actual de treball de PKIX per a desenvolupar un protocol de validaci de certificats que sadapti a les necessitats de dispositius clients que no tenen gaire capacitat de procs ni demmagatzematge. A ms de les funcions aportades pel protocol OCSP, lSCVP ofereix serveis relacionats amb la recerca i el processament de cadenes de certificaci. Aix, quan un client vol verificar una signatura digital, no li cal construir-se tota la ruta de certificaci, des del certificat que ha estat utilitzat per a generar la signatura fins a lautoritat de certificaci arrel, i validar lestat de tots aquests certificats. Simplement pot demanar per lestat dels certificats associats al certificat de la signatura que vol verificar i el servidor sencarregar de crear tota la cadena de certificaci i validar-ne cada un dels components.
15
2.7. Autoritat de segellat de temps

* En angls, time stamping authority.
Lautoritat de segellat de temps* (TSA) s lencarregada de signar un missatge amb la finalitat de provar que existia abans dun determinat instant de temps.
En el document de definici del servei, sespecifica el protocol basat en missatges de petici i resposta que permeten associar marques temporals de confiana als documents. La necessitat duna autoritat de segellat de temps s important per a la propietat de no-repudi. Els serveis de no-repudi han de poder establir lexistncia dunes dades abans de determinats moments. El paper de la TSA consisteix a segellar aquestes dades per tal destablir-ne levidncia. Alguns exemples en qu la TSA t un paper important sn: a) Verificaci de la signatura digital dun document: si el certificat corresponent ha estat revocat, el segell de temps ens permetr establir si en el moment en qu es va efectuar la signatura del document, el certificat encara era vlid o no. b) Lliurament de documents abans duna data lmit: el segell de temps ens permet indicar el moment en qu es va fer el lliurament de determinada informaci. c) Auditories: el segell de temps permet tenir datades totes les entrades dels histrics. Perqu el segellat de temps sigui vlid, lestructura de dades que el cont ha destar protegida criptogrficament i, a ms, la marca de temps que porta sha dhaver obtingut duna font de confiana. Aix es pot assegurar amb la utilitzaci de provedors oficials de valors temporals basats en el temps coordinat universal (UTC, Universal Time Coordinated), que garanteixen una alta precisi en les dades temporals que subministren. Els passos per a posar un segell de temps en un missatge sn els segents: 1) Es calcula un resum digital de les dades que es volen segellar. 2) Senvia el resum a una TSA, que hi afegeix la data i lhora, signa tot el bloc amb la seva clau privada i torna el resultat al client. 3) El client verifica la signatura i comprova que la TSA ha signat el hash de les seves dades i hi ha afegit un segell de temps actual.
16
3. Models de confiana
Hem vist que per a treballar amb criptografia de clau pblica s necessari ls duns certificats que ens assegurin la correspondncia entre la clau pblica i algun atribut, tpicament la identitat de lentitat o la persona propietria del certificat. Per els mtodes de certificaci absoluts sn impossibles, ja que un certificat no es pot certificar ell mateix. Per aquesta ra shan proposat diferents mtodes que pretenen tractar aquesta situaci: el model distribut de xarxa de confiana, el model pla, el model jerrquic, el model de navegaci per llista de confiana, el model de certificats creuats i el model Bridge-CA.
3.1. El model distribut El sistema distribut de xarxa de confiana s el model ms senzill dutilitzar, adequat per a un grup petit dusuaris que ja tenien tractes abans de la implantaci de la infraestructura de clau pblica.
En el model distribut cada usuari crea i signa certificats per a la gent que coneix. No sha de desenvolupar cap infraestructura central amb una tercera entitat de confiana que doni fe de la identitat dels usuaris.
Un exemple daquest sistema s el programari PGP, que correspon a les sigles de Pretty Good Privacy*. Es tracta dun projecte iniciat a principi dels anys 90 per Phill Zimmerman. Amb el pas del temps, el PGP sha convertit en un dels mecanismes ms populars i fiables per a proporcionar serveis criptogrfics en les comunicacions, sobretot per correu electrnic. El programari PGP assumeix que noms els usuaris individuals tenen competncies per a decidir en qui confien i en quin grau; els mateixos usuaris signen o donen autenticitat als certificats. Si un usuari A es vol comunicar amb un usuari B, shauran dintercanviar les claus pbliques per un canal insegur. Aquestes claus estaran empaquetades en un format de certificat autosignat que, a ms, podr ser signat per altres persones. Per tal dassegurar que les claus pbliques pertanyen efectivament a cada usuari, tant A com B calculen el valor del hash de les seves claus i se lintercanvien per un canal insegur diferent al que han fet servir per a intercanviar-se la clau (per exemple, per telfon o correu regular). Els usuaris calculen el hash de la clau del certificat que han rebut i el comparen amb el que els han enviat; si coincideixen, assumeixen que la clau s autntica.
* En angls, privadesa prou bona.
17
En aquest model, hem de distingir dos tipus de confiana: La que ens permet creure en la validesa duna clau, s a dir, la que ens permet refiar-nos que aquella clau pertany a aquella persona. La que ens permet confiar en una persona com a certificadora de claus (aquesta confiana es basa en una decisi personal, i no en algorismes matemtics). No hem doblidar que el fet que un certificat sigui autntic no ens diu res del propietari. Per exemple, hom pot tenir la seguretat que una clau pertany a una persona, per aquesta persona es podria dedicar a signar tots els certificats que li arribessin sense assegurar-se de la seva autenticitat, de manera que en cap cas es mereixeria la nostra confiana. En el cas del PGP, cada usuari guarda les claus pbliques en unes estructures denominades anells de claus*. Una clau s vlida si est signada (certificada) pel mateix usuari propietari de lanell o per prou persones de fiar. Cada clau t associat un nivell de confiana que estableix fins a quin punt es confia en els certificats emesos per aquesta clau. Com ms baix s el nivell de confiana, ms certificats cal per a validar la clau. Quan volem validar el certificat dun usuari qualsevol, fem servir aplicacions de cerca de rutes de certificaci per a crear una cadena de confiana adaptada a les nostres necessitats. Donem a laplicaci lidentificador de clau del nostre certificat i lidentificador del certificat per validar. El servidor de rutes retorna un resultat com el segent:
* En angls, key rings.
Lusuari user x confirma amb lemissi duna signatura que la clau B pertany realment al user B. Per altra banda, com que nosaltres (user A) hem signat la clau del user x podem confirmar que la clau B pertany a lusuari esperat. A ms, hi ha un altre cam de validaci que tamb va des de la nostra clau fins a la del user B. s important que tothom signi claus perqu altres usuaris es puguin beneficiar de les signatures. Totes aquestes signatures formen una espcie de xarxa, i per aix es diu que el PGP s un model de xarxa de confiana.
18
El PGP fa servir dues formes diferents de clau pblica: RSA (amb funci de hash MD5) i Diffie-Hellman (amb funci de hash SHA-1), amb longitud de clau de fins a 2.048 (RSA) o 2.096 (DH). Els algorismes de clau simtrica que pot utilitzar sn CAST (predeterminat), IDEA i TripleDES.
3.2. El model pla El model pla s el sistema ms senzill dinfraestructura de clau pblica que inclou una nica autoritat de certificaci com a tercera part de confiana encarregada de lemissi i la gesti dels certificats dels subscriptors. Els usuaris poden validar la identitat dels subscriptors a partir del certificat de lautoritat de certificaci. Lautoritat de certificaci posseeix un certificat que ella mateixa ha generat i en el qual els usuaris hi dipositen la confiana.
En un certificat autosignat, la clau pblica que se certifica correspon a la clau privada que sutilitza per a signar el certificat. El nom de lemissor i el titular del certificat sn el mateix.
El model pla sacostuma a fer servir en lmbit de les intranets. Per a entorns ms extensos i oberts, aquest model sha ampliat al model jerrquic.
3.3. El model jerrquic El model jerrquic representa la implementaci ms tpica duna infraestructura de clau pblica.
En el model jerrquic, els certificats dels subscriptors i les entitats finals estan signats per una entitat externa que tamb sidentifica amb certificats que emetr una autoritat de certificaci de jerarquia superior.
Els certificats de lautoritat de certificaci de jerarquia superior poden estar a la vegada certificats per altres autoritats de certificaci, i aix successivament, fins a arribar a una autoritat de certificaci que t un certificat autosignat. Aquesta autoritat de certificaci sanomena autoritat de certificaci arrel*, i les que en depenen sn les autoritats de certificaci subordinades. Si els usuaris
* En angls, root CA.
19
de la infraestructura de clau pblica confien en lautoritat de certificaci arrel, aquest vot de confiana sestendr per tota la jerarquia.
Els certificats sestructuren de manera jerrquica; aix, per a verificar lautenticitat dun certificat un usuari pot comprovar la signatura de lautoritat que el va emetre, que a la vegada tindr un altre certificat expedit per una altra autoritat de nivell superior. Daquesta manera, anem pujant per la jerarquia fins a arribar al nivell ms alt, que estar ocupat per un certificat que gaudeixi de la plena confiana de tota la comunitat. Les claus pbliques dels certificats de ms alt nivell fins i tot es publiquen en suport paper perqu qualsevol les pugui verificar.
El PKIX El PKIX s la plataforma dinfraestructura de clau pblica ms important que utilitza el model jerrquic de confiana.
3.4. El model de navegaci per llista de confiana Hem vist que el model jerrquic requereix que sestableixi una nica autoritat de certificaci arrel en la qual tots els usuaris dipositin confiana. Idealment aquesta autoritat de certificaci hauria de tenir abast mundial i lorganitzaci que la gestions hauria de ser prou reconeguda i prestigiosa com perqu qualsevol usuari sen refis. En la prctica aix no s aix. Hi ha moltes i molt diferents autoritats de certificaci arrels, i cadascuna ofereix servei a petites comunitats dusuaris. Per a interconnectar aquestes illes dinfraestructures de clau pblica han sorgit formes hbrides del model jerrquic que permeten la interfuncionalitat entre diferents grups dusuaris controlats per una autoritat de certificaci arrel.
La soluci ms estesa per a interconnectar infraestructures de clau pblica jerrquiques s el model de navegaci per llista de confiana, tamb conegut com model centrat en lusuari, en qu cada aplicaci final t una llista de les claus pbliques de totes les autoritats de certificaci en qu confia.
20
Aquest model, implementat en la majoria de navegadors web (Netscape, Mozilla, Explorer), permet a lusuari un gran nivell de flexibilitat per a afegir i esborrar autoritats de certificaci de la seva llista de confiana. Laccs a aquesta llista de confiana hauria destar totalment protegit contra modificacions externes, ja que determina en quines autoritats de certificaci confiem i, per extensi, en quins altres usuaris (certificats per aquestes autoritats de certificaci).
El principal problema daquest sistema s que no hi ha cap diferncia entre una infraestructura de clau pblica forta i una de dbil. Per exemple, la majoria dusuaris de certificats no miren quina poltica t un certificat especfic abans de confiar-hi. Aix, la majoria dinfraestructures de clau pblica comercials incloses en la llista dels navegadors no inclouen molts dels controls que els diferents governs exigeixen a les autoritats de certificaci. Un avantatge daquest model s que cada aplicaci pot triar confiar en un conjunt diferent dautoritats de certificaci.
3.5. El model de certificats creuats En el model de certificats creuats, les autoritats de certificaci arrel de cada comunitat dusuaris emeten certificats per a altres autoritats de certificaci que tenen funcions i poltiques equivalents a les seves. Com en el model jerrquic, cada usuari noms confia en una autoritat de certificaci arrel, per en aquest model, lautoritat de certificaci arrel s dmbit local, i no pas central, com en aquell. La interconnexi entre diferents illes dinfraestructures de clau pblica es fa pel certificat creuat duna autoritat de certificaci a una altra.
Vegeu el model jerrquic en el subapartat 3.3 daquest mdul.
En un certificat creuat, el titular i lemissor sn autoritats de certificaci diferents. Aquest tipus de certificats sutilitzen perqu una autoritat de certificaci pugui certificar la identitat duna altra autoritat de certificaci.
21
Els usuaris finals poden validar els certificats dusuaris daltres comunitats amb el certificat que ha ems lautoritat de certificaci externa en qu confien. Lestructura que lusuari final veu s la duna infraestructura de clau pblica jerrquica, per cada usuari tindr una vista diferent.
El problema bsic daquest model s la dificultat dimplementar aplicacions client capaces de dur-lo a la prctica. Saber si hi ha una cadena de certificaci que enllaci un usuari X amb un usuari Y requereix un esfor de cerca important. Un altre inconvenient s el gran volum de certificats amb qu es treballa. Cada autoritat de certificaci arrel ha demetre un certificat a totes les altres autoritats de certificaci que vol reconixer. Per exemple, per a establir un domini creuat bidireccional entre diferents infraestructures de clau pblica caldria: a) Per a la interconnexi de tres infraestructures de clau pblica:
2 C 3 = 3 = 6 certificats creats 2
b) Per a la interconnexi de cent infraestructures de clau pblica:

2 100 ! = 9.900 certificats creuats C 100 = 100 = 2 98!
El model de certificats creuats permet organitzar les autoritats de certificaci en estructures horitzontals en comptes destructures jerrquiques, semblant a la idea en qu es fonamenta el model distribut.
3.6. El model Bridge-CA La interconnexi de diverses infraestructures de clau pblica per certificats creuats s molt prctica perqu no requereix lestabliment de cap autoritat de
22
certificaci arrel comuna, per t el problema que s un model poc reescalable. Per a resoldre aquest inconvenient va sorgir el model Bridge-CA, que incorpora una autoritat externa que actuar de pont entre les infraestructures de clau pblica que es volen unir. Totes les autoritats de certificaci estableixen una certificaci creuada amb el punt central de referncia, el Bridge-CA, i daquesta manera es crea una comunitat de confiana ms extensa. Per a establir un domini creuat bidireccional entre diferents infraestructures de clau pblica calen: a) Per a la interconnexi de tres infraestructures de clau pblica: 2 3 = 6 certificats creuats b) Per a la interconnexi de cent infraestructures de clau pblica: 2 100 = 200 certificats creuats
El US Federal Bridge-CA El model dautoritat de certificaci US Federal Bridge s un dels projectes pioners en aquest camp. Permetr interconnectar les autoritats de certificaci arrel dels diferents estats i universitats dels Estats Units.
Lestructura del model Bridge-CA s similar a la del model jerrquic. La diferncia bsica rau en el fet que el Bridge-CA no s un punt central de confiana, sin una entitat que facilita la certificaci creuada entre totes les autoritats de certificaci participants. Un usuari que confi en lautoritat de certificaci de la seva jerarquia podr validar certificats daltres jerarquies que hi estiguin unides pel Bridge-CA, per no li caldr confiar-hi explcitament.
Vegeu el model jerrquic en el subapartat 3.3 daquest mdul.
23
4. Cicle de vida de claus i certificats digitals
En aquest apartat veurem el cicle de vida de les claus i dels certificats digitals i, daquesta manera, il lustrarem els processos bsics que sn comuns a totes les infraestructures de clau pblica. Partirem del fet que ja existeix el parell de claus duna autoritat de certificaci i ens basarem en un model de confiana pla. La figura de ms avall il lustra la relaci entre els components bsics duna infraestructura de clau pblica.
Els subscriptors generen un parell de claus criptogrfiques i es registren en una autoritat de registre per tal de poder demanar un certificat digital. Si lautoritat de registre aprova la petici de certificaci, envia les dades a lautoritat de certificaci perqu emeti el certificat. El certificat es publica en un repositori al qual tots els usuaris tenen accs i, daquesta manera, el subscriptor i lusuari poden utilitzar serveis de seguretat per a comunicar-se.
En els subapartats segents descriurem amb ms detall els passos que se segueixen.
4.1. Generaci del parell de claus La primera part del cicle de vida dun parell de claus i del certificat digital relacionat s la generaci de les claus. Segons la poltica de certificaci* (CPS) de lautoritat de certificaci, tant el subscriptor en el seu entorn local com les entitats externes poden generar el parell de claus criptogrfiques. En aquest l* En angls, certification practice statement.
24
tim cas, les claus shan de distribuir als usuaris en fitxers xifrats o targetes criptogrfiques. Les claus criptogrfiques shan de generar dacord amb les necessitats de les aplicacions i els serveis que les utilitzaran. Per exemple, la vida til de les dades que es volen protegir determina la longitud ptima de les claus. Daltra banda, el perode de temps considerat de validesa duna clau o certificat dependr del tipus doperacions que es vulgui efectuar. Per tal de proporcionar un mitj coherent de discernir quines claus sn apropiades per a certes aplicacions i quines no, els certificats contenen un camp amb la informaci del tipus de certificat que representen. Bsicament nhi ha de dos tipus: a) En els certificats de xifratge pot ser necessari tenir una cpia de seguretat de la clau privada per tal de poder recuperar la informaci en clar, si la clau de desxifratge es perd o es destrueix. Aquesta prctica s comuna en lentorn empresarial. b) Els certificats de signatura es fan servir per a donar serveis dautenticaci i de no-repudi, i s important que no hi hagi cap cpia de la clau privada corresponent. Qualsevol sistema de recuperaci de claus per a aquest tipus de certificats ninvalidaria les propietats.
Els navegador Els navegadors disposen deines per a generar les parelles de claus criptogrfiques.
4.2. Registre
El registre s el procs pel qual un subscriptor o entitat final es dna a conixer per primera vegada a una autoritat de certificaci (directament o des duna autoritat de registre) per tal de demanar-hi un certificat.
El subscriptor ha de proporcionar informaci referent a la seva identitat, com el seu nom, un identificador nic, alguna prova didentitat i altra informaci addicional que estigui especificada en la CPS de lautoritat de certificaci. Si ell mateix ha generat el parell de claus criptogrfiques, tamb ha de donar la clau pblica que vol certificar. Tota aquesta informaci sestructura en una petici de certificat amb format PKCS#10. La verificaci de les dades aportades en el procs de registre es fa seguint les directrius establertes en la CPS.
Veurem el format PKCS#10 en el subapartat 6.2 daquest mdul.
4.3. Certificaci
La certificaci s el procs pel qual lautoritat de certificaci emet un certificat, s a dir, signa digitalment la clau pblica i les dades dun subjecte i, per tant, dna fe daquesta correspondncia.
25
El subscriptor proporciona les dades que el certificat ha de contenir per mitj duna petici de certificat PKCS#10. Aquestes dades han estat prviament validades, i sha comprovat que el subscriptor t drets per a tenir un certificat daquestes caracterstiques. En el procs de certificaci tamb es defineix el perode de validesa del certificat i ls que sen podr fer. Un cop generat el certificat, lautoritat de registre (o, si no nhi ha, lautoritat de certificaci) sencarregar de fer-lo arribar al subscriptor i penjar-lo en el directori pblic adequat.
4.4. Recuperaci de claus En algunes situacions s important poder recuperar una clau privada per a accedir a informaci xifrada prviament. Per exemple, una empresa pot necessitar accs a documents prviament xifrats per un empleat que shagi donat de baixa de lempresa.
Lautoritat de certificaci pot oferir sistemes de recuperaci de claus mitjanant un sistema de cpies de seguretat al qual noms puguin accedir els usuaris autoritzats per obtenir les dades. El sistema ha de garantir que les claus no es poden comprometre.
4.5. Revocaci de certificats
La revocaci de certificats s el procs pel qual una autoritat de certificaci invalida un certificat abans del seu perode dexpiraci.
Hi ha diverses raons per les quals un certificat pot ser revocat: a) Comproms de la clau privada associada al certificat. b) Canvi del subscriptor per un altre provedor de serveis dinfraestructura de clau pblica. c) Canvi en la informaci que porta el certificat (nom del subscriptor, companyia a qu pertany, etc.). d) Substituci prematura de la parella de claus de lautoritat de certificaci. En qualsevol daquestes situacions, el certificat deixa de tenir utilitat i el subscriptor ho ha de notificar a lautoritat de certificaci/registre. La notificaci es
26
pot fer en persona, per correu electrnic signat o per qualsevol altre canal autenticat. La clau privada corresponent al certificat revocat es pot utilitzar per a autenticar una petici de revocaci, per per raons bvies, si la petici s la causa del comproms de la clau, aquesta no valdr per a lautenticaci en la generaci dun nou certificat. El mtode predominant de distribuci de la informaci dels certificats que han estat revocats sn les llistes de revocaci de certificats (CRL).
Una llista de revocaci de certificats (CRL) s una llista dels certificats que han estat revocats, signada i datada per lautoritat de certificaci corresponent.
Lautoritat de certificaci publica les llistes de revocaci de certificats en un servei de directori a intervals regulars, i s responsabilitat del client obtenir i comprovar la llista per determinar la validesa dels certificats. El temps transcorregut entre la revocaci dun certificat i la publicaci de la llista de revocaci de certificats que en porta la informaci s crtic, ja que hi ha una escletxa de confiana en el certificat en un moment en qu la clau privada pot estar compromesa i durant el qual es poden prendre decisions crtiques.
El cicle de publicaci de CRL El cicle de publicaci de les CRL s crtic en una aplicaci dautoritzaci dusuaris per a accedir a un registre amb dades financeres.
4.6. Renovaci de certificats La renovaci dun certificat digital pot venir donada bsicament per dos motius: Prdua de validesa del certificat (caducitat del certificat, revocaci per canvi dinformaci del certificat, etc.). Prdua de validesa de les claus que certifica (revocaci del certificat per comproms de la clau privada associada). El certificat digital caduca quan nexpira el perode de validesa. El perode de validesa dun certificat sestableix dacord amb les restriccions duna srie de factors: lalgorisme de clau pblica i la llargada de la clau, la utilitzaci del certificat, els acords financers i de manteniment amb lautoritat de certificaci, els requisits del cicle de vida dels serveis i el programari que el certificat necessita. La renovaci del certificat digital per prdua de validesa s simple: la petici de renovaci se signa amb la clau privada associada al certificat que es vol renovar, que encara t validesa. Daquesta manera, el subscriptor es pot autenticar davant lautoritat de certificaci sense haver de tornar a passar tota la fase de registre. En aquest cas es pot certificar el mateix parell de claus o generar-
Els perodes de renovaci El perode apropiat per a una clau RSA de 1.024 bits que sutilitzi per a autenticaci s duns dos anys.
27
ne un altre parell. Normalment, en cas de caducitat del certificat es genera un nou parell de claus, ja que sutilitza justament la data de caducitat dels certificats per a limitar el temps de vida de les claus i reduir els possibles atacs al criptosistema per fora bruta. En el cas de revocaci del certificat per comproms de la clau privada, la renovaci del certificat no s tan transparent. La infraestructura de clau pblica ha doferir mitjans en els quals no intervingui el parell de claus per a anunciar que el certificat vell deixa de ser vlid en favor dun nou certificat. Sovint sassocia una contrasenya al procs de generaci del certificat per tal de poder-lo revocar. En aquest cas, la renovaci del certificat passa per la generaci dun nou parell de claus i lemissi dun nou certificat per a les claus noves. El pitjor cas s quan la clau compromesa s la de la prpia autoritat de certificaci. Aleshores sha dinvalidar tant el certificat de lautoritat de certificaci com el de tots els subscriptors que en depenien. El fet que lautoritat de certificaci tingui les claus compromeses fa dubtar de la confiana en qualsevol missatge electrnic de lautoritat de certificaci que notifiqui aquest fet (qui signa el missatge, si les claus no sn vlides?). Una manera de pal liar els efectes de la caiguda duna autoritat de certificaci s que es pregenerin i distribueixin unes claus substitutries que sutilitzaran en cas de comproms de les nominals. A ms, caldr reemetre certificats a tots els subscriptors, de manera que estiguin signats per una clau no revocada.
28
5. Estructures de dades bsiques de PKIX
En aquest apartat ens centrarem en les estructures de dades definides per la IETF en els seus estndards del grup PKIX.
5.1. Certificats X.509 El format de certificats ms mpliament acceptat en infraestructura de clau pblica est definit per lISO/IEC JTC1 SC21 i es coneix com X.509v3.
LX.509 El terme X.509 ve de lespecificaci X.500 de serveis de directori.
Lestndard internacional X.509v3, que tamb es publica amb el nom dITU-T Recommendation X.509, s important per dues raons bsiques: defineix el marc per a la provisi de serveis dautenticaci i un format de certificat per a les claus pbliques.
El format dels certificats X.509 ha evolucionat a partir de tres versions en diferents edicions de lestndard. La primera versi va aparixer el 1988. El 1993 es va revisar i se nobtingu la versi 2, en qu shi van afegir dos camps opcionals didentificaci nica. Ls de lX.509 junt amb lInternet privacy enhanced mail (PEM) va fer sorgir la necessitat de dotar el certificat de ms flexibilitat. El juny de 1996 va aparixer la versi 3 del certificat, que inclou la possibilitat de tenir camps dampliaci. LX.509 es va dissenyar com un marc general dautenticaci per a donar suport als serveis de directori X.500. Aquest carcter obert origina mltiples possibilitats per a alguns dels camps del certificat (principalment en les ampliacions). Per a regular ls de les ampliacions i el seu significat, apareixen els perfils de certificats, que concreten i limiten les combinacions datributs que es poden definir per a cada tipus de certificat. El perfil de certificat ms ests s el definit pel grup de treball PKIX de la IETF. Aquest grup sencarrega tant de definir el perfil de certificats i llistes de revocaci, com de desenvolupar especificacions i protocols relacionats amb lentorn dinfraestructura de clau pblica. En els subapartats segents veurem la manera de designar les entitats participants en lestructura de clau pblica, i desprs comentarem el format general dun certificat i nanalitzarem cadascun dels camps.
5.1.1. Nom dels components dun certificat Els certificats X.509, com la resta de components de la infraestructura de clau pblica, es designen per un nom distingit.
29
Un nom distingit (DN) s un conjunt datributs amb valors associats. Aquest tipus destructura permet que cada organitzaci decideixi quins atributs sn interessants per a identificar les entitats dins de la seva empresa.
CN: OU: O: C:
Atributs ms usuals dels noms distingits Nom com Unitat organitzativa Organitzaci Pas Localitat Estat Carrer Ttol de la persona
Els atributs ms habituals es mostren a la taula del marge. Per a alguns usos del certificat, el sistema de noms per noms distingits pot resultar insuficient. En aquests casos es fan servir uns camps especials del certificat anomenats noms alternatius que permeten especificar ladrea de correu electrnic, ladrea IP duna web, el DNS, el nom EDI, etc.
L: S: STREET: T:
Camps especials Les adreces de correu electrnic sespecifiquen en el camp Nom alternatiu del titular (subjectAltName) seguint el format rfc822Name definit en [RFC822].
5.1.2. Estructura dun certificat
En un certificat hi ha tres tipus principals de camps:
a) Bsics: camps que aporten informaci sobre lautoritat de certificaci que ha ems el certificat, lentitat/subscriptor a qu pertany la clau pblica, la mateixa clau pblica, i el perode de validesa i la identificaci del certificat.
Llenguatge dels certificats Els certificats X.509, com les altres estructures definides per PKIX, estan especificades en llenguatge ASN.1 (Abstract Syntax Notation One).
b) Necessaris per a la signatura: camps que utilitzar qui rebi el certificat per a comprovar que el document est signat correctament. c) Ampliacions: camps que han aparegut per a cobrir les noves necessitats datributs en un certificat. Alguns dels possibles usos dels camps dampliaci sn la millora de la gesti de lherncia de certificaci, les poltiques de seguretat o les dades sobre lusuari i la seva clau. Les ampliacions poden estar definides en estndards o per una organitzaci particular que faci s de certificats. Els camps bsics dun certificat X.509v3 sn els segents:
Camp version serialnumber signature issuer validity subject subjectPublicKeyInfo Descripci Identifica el nmero de versi del certificat: v1, v2, v3. Enter assignat per lautoritat de certificaci. Identifica unvocament el certificat duna autoritat de certificaci. Ha de coincidir amb lalgorisme de signatura dels camps necessaris per a la signatura. Nom distingit de lautoritat de certificaci que ha signat i ems el certificat. Dos camps que identifiquen el perode en qu el certificat s vlid. Nom distingit que identifica el propietari del certificat. Camp amb informaci sobre la clau pblica per la qual semet el certificat.
30
Camp issuerUniqueID subjectUniqueID extensions
Descripci Camp opcional i poc utilitzat que permet la reutilitzaci de noms dautoritat de certificaci. Camp opcional que permet la reutilitzaci de noms de titulars. Camp opcional que cont els camps dampliacions del certificat.
Els camps necessaris per a la signatura sn:

Identificaci dels certificats Camp Descripci Cont lidentificador de lalgorisme de hash (MD2, MD5, SHA-1) i lalgorisme de clau pblica (RSA, DSA) que sha utilitzat en la signatura del certificat digital. Cont el valor de la signatura dels camps bsics i les ampliacions del certificat amb lalgorisme de signatura descrit en el camp anterior. El nmero de srie del certificat, junt amb el nom de lautoritat de certificaci, ha de servir per a identificar unvocament un certificat en qualsevol context.
signatureAlgorithm
signature
Totes les ampliacions apareixen dins del camp extensions del certificat, i cadascuna est formada per tres subcamps:
Camp duna ampliaci extnID
Descripci Identificador unvoc de lampliaci que representa. Valor lgic que marca si lampliaci s crtica o no. Les aplicacions poden ignorar les ampliacions no crtiques en cas que no les reconeguin. La presncia duna ampliaci crtica no reconeguda provoca el rebuig del certificat. Cont el valor de lampliaci.
critical
extnValue
Cada ampliaci noms pot aparixer una vegada en cada certificat.
A continuaci, comentem algunes de les ampliacions ms destacades dels certificats i nindiquem el contingut del subcamp extnValue :
Tipus dampliaci subjectAltName issuerAltName keyUsage
Descripci Nom alternatiu del titular (adrea de correu electrnic, etc.). Nom alternatiu de lautoritat de certificaci emissora. Defineix i limita els possibles usos de la clau certificada. Complement del keyUsage i el basicConstraints per a delimitar els possibles usos de la clau dins les necessitats particulars duna organitzaci. Distingeix si el certificat s duna entitat final (fals) o duna autoritat de certificaci (veritable). Permet limitar la longitud de cadena de certificaci. Limita lespai de noms que poden utilitzar els certificats segents de la cadena.
extKeyUsageSyntax
basicConstraints
nameConstraints
31
Tipus dampliaci certificatePolicies policyMappings
Descripci Informaci sobre la CPS de lautoritat de certificaci. Identifica les poltiques duna autoritat de certificaci amb les duna altra. Limita la verificaci del cam de certificaci segons unes poltiques. Limita ls de la poltica anyPolicy a un nombre de certificats de la cadena. Especifica perodes de validesa per a la clau privada que sn diferents dels del certificat. Identificador nic de la clau pblica necessari per a validar el certificat. til quan una autoritat de certificaci t diverses claus de signatura. Identificador nic de certificats que fa el hash sobre la clau pblica o genera un nombre nic. Indica la localitzaci de les llistes de revocaci de certificats relacionades amb el certificat a partir duns punts de distribuci. Indica on trobar informaci de les llistes de revocaci de certificats ms recents. Ampliaci privada definida per PKIX que indica com accedir a informaci i serveis que lautoritat de certificaci emissora proporciona.
policyConstraints
inhibitAnyPolicy
privateKeyUsagePeriod
authorityKeyIdentifier
subjectKeyIdentifier
crlDistributionPoints
fraeshestCRL
authorityInformationAccess
Lampliaci keyUsage, que defineix els propsits del certificat, s una de les ms importants. El PKIX recomana que en cas de fer-la servir, aquesta ampliaci es marqui com a crtica. Els valors que pot prendre sn una combinaci de les opcions segents:
Valors de keyUsage digitalSignature nonRepudiation keyEncipherment dataEncipherment
Descripci El certificat pot verificar signatures de documents. Es poden verificar signatures amb la propietat de no-repudi. La clau pot ser utilitzada per a transportar claus. La clau es pot fer servir per a xifrar dades dusuari que no sn claus. Sutilitza la clau per a algorismes destabliment duna clau de sessi. La clau es fa servir per a validar la signatura daltres certificats (emprat en autoritats de certificaci). Sutilitza conjuntament amb keyAgreement per a limitar ls de la clau a xifrar dades durant el procs destabliment de la clau. Es fa servir conjuntament amb keyAgreement per a limitar ls de la clau a desxifrar dades durant el procs destabliment de la clau. Camp opcional que permet la reutilitzaci de noms de titulars.
keyAgreement
keyCertSign
encipherOnly
decipherOnly
subjectUniqueID
32
Lestructura de dades del certificat indicat s la segent:
Certificate: SEQUENCE (1006) toBeSigned SEQUENCE (726) version [0] INTEGER (1) 0x02 (2) serialNumber INTEGER (1) 0x24 (36) signature SEQUENCE (13) algorithm OBJECT IDENTIFIER (9) pkcs1-sha1WithRsaSignature parameters TYPE (2) NULL (0) issuer SEQUENCE OF (71) OU=Coyote Subordinate CA (MIR), O=UOC, C=ES validity SEQUENCE (30) notBefore UTCTime (13) 030929144413Z notAfter UTCTime (13) 040929144251Z subject SEQUENCE OF (65) CN=user, OU=Criptografia, O=UOC, C=ES subjectPublicKeyInfo SEQUENCE (159) algorithm SEQUENCE (13) algorithm OBJECT IDENTIFIER (9) pkcs1-rsaEncryption parameters TYPE (2) NULL (0) subjectPublicKey BIT STRING (141) Encapsulates TYPE (140) with rSAPublicKey SEQUENCE (137) smodulus INTEGER (129) 0x00D0A60F7EF71D4FCB342982E2333C575392AFF9B.. exponent INTEGER (3) 0x010001 (65537) issuerUId [1] IMPLICIT BIT STRING OPTIONAL NOT PRESENT subjectUId [2] IMPLICIT BIT STRING OPTIONAL NOT PRESENT extensions [3] SEQUENCE OF (361) extension SEQUENCE (14) extnId OBJECT IDENTIFIER (3) id-ce-keyUsage critical BOOLEAN (1) TRUE extnValue OCTET STRING (4) Encapsulates TYPE (4) with BIT STRING (2) 03 F8 extension SEQUENCE (29) extnId OBJECT IDENTIFIER (3) id-ce-extKeyUsage critical BOOLEAN (1) FALSE DEFAULT extnValue OCTET STRING (22) Encapsulates TYPE (22) with SEQUENCE OF (20) OBJECT IDENTIFIER (8) id-kp-clientAuth OBJECT IDENTIFIER (8) id-kp-emailProtection extension SEQUENCE (17) ... signatureAlgorithm SEQUENCE (13) algorithm OBJECT IDENTIFIER (9) pkcs1-sha1WithRsaSignature parameters TYPE (2) with NULL (0) signature BIT STRING (257) 00 73E9098140B1DD4BBE66F0487AD1EDC85E4B...
5.2. Llistes de revocaci (CRL)
Les llistes de revocaci de certificats serveixen perqu una autoritat de certificaci pugui distribuir informaci sobre els certificats que ha ems i han estat revocats.
33
Una llista de revocaci de certificats (CRL) s una estructura de dades signada per lautoritat de certificaci emissora que cont les dades necessries per a determinar lestat dun certificat.
En els certificats X.509 es mant informaci sobre on es pot obtenir la llista de revocaci de certificats de lautoritat de certificaci emissora, en concret a lampliaci crlDistributionPoint. En el mateix estndard X.509 sespecifica un format per a les llistes de revocaci de certificats. La publicaci de la primera versi de lestndard va ser lany 1988. De la mateixa manera que va passar amb els certificats (vegeu el subapartat 5.1.2), ms tard, a la versi 2, lestndard es va modificar amb lobjectiu dintroduir-hi els camps dampliaci. En els subapartats segents veurem els tipus bsics de llistes de revocaci de certificats, com es distribueixen i quin s el format de la seva estructura de dades.
5.2.1. Tipus de llistes de revocaci de certificats Hi ha tres tipus bsics de llistes de revocaci de certificats: CRL simple, delta CRL i CRL indirecta.
A la figura veiem el tipus dinformaci que mostra MS Internet Explorer dun certificat.
Una llista de revocaci de certificats simple s un fitxer seqencial que cont una llista dels certificats revocats.
Taxes de revocaci La taxa de revocaci de certificats se situa en un 10% en un any.
Aquest fitxer creix a mesura que el temps passa i esdev intractable i ineficient. Per aquest motiu, han sorgit altres formes de llistes de revocaci de certificats que proporcionen a laplicaci final noms el conjunt dinformaci de revocaci que hi pot ser rellevant.
Una delta CRL s una llista de revocaci de certificats que complementa la informaci continguda en una altra llista de revocaci de certificats base.
La delta CRL est dissenyada per a reduir les dimensions de la llista que es transmet a lentitat final. Inicialment, i desprs en intervals regulars planificats, es publica una llista de revocaci de certificats completa la CRL base que cont informaci de totes les revocacions conegudes. A partir daquest
34
punt semeten una srie de llistes dactualitzaci que contenen els canvis que shan produt des de lltima publicaci duna delta CRL o CRL base. Cada actualitzaci es distribueix com una llista de revocaci de certificats, i lautoritat de certificaci lemet i la signa de la mateixa manera que una llista de revocaci de certificats.
Una CRL indirecta s una llista de revocaci de certificats que cont informaci de revocaci de diverses autoritats de certificaci.
Aquests tipus de llistes de revocaci de certificats sutilitzen per a reduir el nombre de llistes de revocaci de certificats que s necessari obtenir per a poder comprovar la validesa dun certificat. Per tal que una entitat final pugui utilitzar una CRL indirecta, shi ha de confiar com es confia en lautoritat de certificaci que emet el certificat.
5.2.2. Punts de distribuci de llistes de revocaci de certificats
Els punts de distribuci de llistes de revocaci de certificats serveixen per a fragmentar la llista de revocaci de certificats global duna autoritat de certificaci en unes quantes de ms petites; cada subconjunt engloba un nombre determinat de certificats i/o un subconjunt de raons de revocaci. Els certificats X.509 contenen un apuntador al punt de distribuci corresponent.
Amb ls de punts de distribuci de llistes de revocaci de certificats disminueix el consum de recursos de xarxa (ample de banda i temps de transmissi) per la menor dimensi de cada llista de revocaci de certificats dun punt de distribuci respecte duna nica llista que inclogus les revocacions de tots els certificats.
5.2.3. Format de les llistes de revocaci de certificats En una llista de revocaci de certificats podem trobar quatre tipus principals de camps: a) Bsics: camps que aporten informaci sobre lautoritat de certificaci que ha ems la llista de revocaci de certificats, la data en qu sha actualitzat, la data de la segent actualitzaci i els certificats que han estat revocats. b) Necessaris per a la signatura : camps que utilitzar qui rebi la llista de revocaci de certificats per a comprovar que el document est signat correctament.
35
c) Ampliacions de la CRL: ampliacions que proporcionen mtodes per a associar atributs addicionals a la llista de revocaci de certificats. Poden ser definides en estndards o per organitzacions particulars. d) Ampliacions de lentrada de la CRL: ampliacions que proporcionen informaci addicional sobre les entrades de la llista de revocaci de certificats. Els camps bsics duna llista de revocaci de certificats sn els segents:
Camp version signature issuer thisUpdate nextUpdate revokedCertificates crlExtensions Descripci Identifica el nmero de versi de la llista de revocaci de certificats: v1, v2. Ha de coincidir amb lalgorisme de signatura dels camps necessaris per a la signatura. Nom distingit de lautoritat de certificaci que ha signat i ems la llista de revocaci de certificats. Data demissi de la llista de revocaci de certificats. Data posterior en qu semetr la segent llista de revocaci de certificats. Llista amb els certificats revocats. Camp opcional que cont els camps dampliacions de la llista amb els certificats revocats.
Els camps necessaris per a la signatura sn:

Camp signatureAlgorithm Descripci Cont lidentificador de lalgorisme utilitzat per a signar la llista de revocaci de certificats. s un camp anleg al que trobem en un certificat. Cont la signatura de la llista de revocaci de certificats segons lalgorisme establert.
signature
Les ampliacions, que tenen el mateix format que les definides per a lestndard X.509, sn dels tipus segents:
Tipus dampliaci authorityKeyIdentifier issuerAltName crlNumber deltaCrlIndicator Descripci Identifica la clau de lautoritat de certificaci amb la qual es pot validar la llista de revocaci de certificats. Nom alternatiu de lautoritat de certificaci emissora. Permet determinar quan una llista de revocaci de certificats nactualitza una altra. Indica que es treballa amb llista delta de revocaci de certificats i identifica la llista de revocaci de certificats base. Indica on es troba la llista de revocaci de certificats i el tipus de certificats que hi haur a la llista (dautoritats de certificaci, de subscriptors, revocats per un determinat motiu, etc.).
Vegeu lestndard X.509 en el subapartat 5.1 daquest mdul.
issuingDistributionPoint
Les ampliacions dentrada a la llista de revocaci de certificats apareixen en el subcamp crlEntryExtensions de cada entrada de la llista de certificats revocats continguts en el camp revokedCertificates. Poden tenir els valors segents:
36
Ampliaci dentrada reasonCode holdInstructionCode
Descripci Identifica la causa per la qual sha revocat un certificat. Indica lacci que cal dur a terme quan es troba un certificat que ha estat susps. Cont la data en qu se sap o se sospita que el certificat es va invalidar o la clau va ser compromesa. Pot ser anterior a la data de revocaci. Identifica lemissor del certificat en una entrada duna llista de revocaci de certificats indirecta. Indica on es troba la llista de revocaci de certificats i el tipus de certificats que hi haur a la llista (dautoritats de certificaci, de subscriptors, revocats per un determinat motiu, etc.).
invalidityDate
certificateIssuer
issuingDistributionPoint
37
6. Format i procediments per a generar missatges: PKCS
Les normes PKCS, o public-key cryptography standards, sn un conjunt despecificacions desenvolupades en els laboratoris RSA amb lobjectiu destablir una norma comuna a la indstria sobre els formats de les dades utilitzades en criptografia de clau pblica. En realitat no sn estndards, sin una aproximaci creada ad hoc per una nica empresa amb el suport i la col laboraci daltres fabricants (Apple, Microsoft, DEC, Lotus, Sun, MIT, etc.). La primera publicaci de PKCS es va fer el 1991 i, des daleshores, desenvolupadors de tot el mn els han referenciat i implementat mpliament. Algunes contribucions de les sries PKCS han estat adoptades com a estndards formals i de facto, com PKIX, SET; S/MIME i SSL. Actualment hi ha deu normes PKCS: PKCS #1, #3, #5, #7, #8, #9, #10, #11, #12 i #15. Els PKCS #13 i #14 encara no han estat publicats, els PKCS#2 i #4 han estat incorporats en el PKCS#1, i el PKCS#6 sha retirat en favor de la versi 3 de lestndard X.509. Els PKCS inclouen normes que defineixen tant la sintaxi duna estructura de dades independentment de lalgorisme, com formats especfics per a un algorisme concret.
PKCS 1 3 Descripci Defineix els mecanismes per a xifrar i signar dades amb el criptosistema de clau pblica RSA. Tamb defineix una sintaxi, idntica a X.509, per a les claus pbliques i privades. Defineix un protocol Diffie-Hellman per a lintercanvi de claus. Descriu un mtode per a xifrar una cadena de text amb una clau secreta derivada duna frase de pas. El seu objectiu primari s permetre la transmissi xifrada de claus privades entre ordinadors, com es descriu en el PKCS#8, encara que pot ser utilitzada per a xifrar missatges. Fa servir MD2 o MD5 per a produir una clau a partir duna frase de pas. Aquesta clau sutilitza per a xifrar amb DES (en mode CBC) el missatge en qesti. Defineix una sintaxi general per als missatges que inclouen millores criptogrfiques, com signatures digitals o xifratge. Descriu el format de la informaci de la clau privada. Aquesta informaci inclou una clau privada per a algun algorisme de clau pblica i, opcionalment, un conjunt datributs. Defineix els tipus datributs seleccionats per utilitzar en altres estndards PKCS. Descriu una sintaxi per peticions de certificaci. Defineix una interfcie de programaci independent de la tecnologia, anomenada Cryptoki, per a dispositius criptogrfics com targetes intel ligents i targetes PCMCIA. Especifica un format portable per a emmagatzemar i transportar claus privades dusuari, certificats, secrets diversos, etc. Definir els mecanismes per a xifrar i signar dades utilitzant criptografia basada en corbes el lptiques. Cobreix la generaci de nombres pseudoaleatoris. Complement del PKCS#11 que defineix el format de les credencials criptogrfiques emmagatzemades en dispositius criptogrfics.
8 9 10 11
12 13 14 15
38
6.1. El PKCS#7
El PKCS#7 descriu una sintaxi general per a dades que poden portar incorporada criptografia, com signatures digitals o sobres digitals. La sintaxi admet recursivitat, de manera que, per exemple, un sobre digital pot ser dins dun altre i una entitat pot signar dades que abans han estat posades dins dun sobre digital.
Els diferents tipus dobjectes PKCS#7 que ens hi trobem sn: data, signedData, envelopedData, signedAndEnvelopedData, digestedData i encryptedData. A continuaci els veurem amb ms detall.
6.1.1. Els data
Es tracta dinformaci en clar que no ha sofert cap tipus de manipulaci criptogrfica.
6.1.2. Els signedData
Lobjecte signedData engloba informaci a la qual sha aplicat una signatura digital. La informaci que porta aquesta estructura de dades s la segent:
signedData version
Descripci Versi de lestndard que es fa servir. Conjunt didentificadors dels algorismes de hash que shan utilitzat per a crear les signatures digitals. Objecte que volem signar. Cadena de certificaci des dels certificats utilitzats per la signatura fins als certificats de les autoritats de certificaci de nivell ms alt. Conjunt de llistes de certificats revocats. Conjunt dinformaci sobre els signants. Versi de lestndard que es fa servir. Identifica el certificat del signant a partir del nom de lautoritat de certificaci que lha ems i el nmero de srie del certificat. Algorisme utilitzat per a resumir el contingut del missatge. Camp opcional que cont un conjunt datributs que han estat signats. til per a incloure la data en qu es genera la signatura. Conjunt datributs que no han estat signats.
digestAlgorithms contentInfo
certificates
crls signerInfo version issuerAndSerialNumber
El contingut signedData de PKCS#7 El tipus de contingut signedData de PKCS#7 proporciona un cas ds degenerat en el qual no hi ha cap signatari del contingut. Aquest format sutilitza per a distribuir cadenes de certificats i llistes de revocaci.
digestAlgorithm
authenticateAttributes
UnauthenticatedAttributes
39
Lobjecte signedData pot portar signatures generades per diversos usuaris. Per a cada signant shaur de generar el resum de les dades per signar amb lalgorisme que aquest especifiqui, i desprs shauran de signar amb la clau privada de lusuari que emet la signatura. Com es veu en la taula, el camp signerInfo inclou altres camps que donen informaci ms detallada sobre com es genera la signatura per a cada usuari. Per a crear una estructura de signatura digital shan de seguir els passos segents: 1) Per a cada signant, es calcula el resum de les dades amb lalgorisme indicat per lusuari que signa. Si el signant defineix atributs autenticats, el resum ser el daquests atributs. Si no, noms es tindr en compte el missatge contingut en contentInfo. 2) Per a cada signant, se signa el resum calculat en el pas anterior utilitzant la clau privada. 3) Per a cada signant, la signatura digital i altra informaci especfica del remitent sagrupen en el camp anomenat signerInfo. 4) Els algorismes que shan utilitzat per a resumir el missatge de tots els remitents, els diferents camps signerInfo i el missatge original sagrupen en un camp signedData. Els passos que haur de seguir el destinatari sn: a) Verificar els resums de cada signant amb la clau pblica daquest. b) Comparar que els resums obtinguts en el pas anterior coincideixen amb els que sobtenen en fer els clculs amb les dades que sautentiquen.
Una signatura digital pot representar-se amb un PKCS#7 que contingui lobjecte signedData.
Exemple de lestructura dun PKCS#7 signedData
PKCS#7: SEQUENCE (2417) contentType OBJECT IDENTIFIER (9) pkcs7-signedData content [0] TYPE (2402) with SEQUENCE (2398) version INTEGER (1) 0x01 (1) digestAlgorithms SET OF (11) SEQUENCE (9) algorithm OBJECT IDENTIFIER (5) secsig-algorithm-sha1 parameters TYPE (2) with NULL (0) contentInfo SEQUENCE (26) contentType OBJECT IDENTIFIER (9) pkcs7-data content [0] TYPE (13) with OCTET STRING (11) Hello World certificates [0] IMPLICIT SET OF (2074) SEQUENCE (997) toBeSigned SEQUENCE (717) version [0] INTEGER (1) 0x02 (2) serialNumber INTEGER (1) 0x13 (19)
40
crls [1] IMPLICIT SET OF OPTIONAL NOT PRESENT signerInfos SET OF (272) SEQUENCE (268) version INTEGER (1) 0x01 (1) issuerAndSerialNumber SEQUENCE (76) issuer SEQUENCE OF (71) OU=Coyote Subordinate CA (MIR), O=UOC, C=ES serialNumber INTEGER (1) 0x13 (19) digestAlgorithm SEQUENCE (9) algorithm OBJECT IDENTIFIER (5) secsig-algorithm-sha1 parameters TYPE (2) with NULL (0) authenticatedAttributes [0] IMPLICIT SET OF (93) SEQUENCE (24) attrType OBJECT IDENTIFIER (9) pkcs9-contentType attrValue TYPE (13) with SET OF (11) OBJECT IDENTIFIER (9) pkcs7-data SEQUENCE (28) attrType OBJECT IDENTIFIER (9) pkcs9-signingTime attrValue TYPE (17) with SET OF (15) UTCTime (13) 030929150419Z SEQUENCE (35) attrType OBJECT IDENTIFIER (9) pkcs9-messageDigest attrValue TYPE (24) with SET OF (22) OCTET STRING (20) 0A4D55A8D... digestEncryptionAlgorithm SEQUENCE (13) algorithm OBJECT IDENTIFIER (9) pkcs1-rsaEncryption parameters TYPE (2) with NULL (0) encryptedDigest OCTET STRING (64) 63103EC00F6001BC760C7996... unauthenticatedAttributes [1] IMPLICIT SET OF OPTIONAL NOT PRESENT
6.1.3. Els envelopedData Lobjecte envelopedData consisteix en un sobre digital. Les dades estan xifrades amb una clau simtrica de sessi i aquesta clau est, al seu torn, xifrada amb les claus pbliques dels destinataris (el sobre digital pot anar dirigit a un o ms usuaris). Les dades que es xifren poden ser de qualsevol tipus; normalment sn objectes data, digestedData o signedData. La informaci que porta una estructura de dades envelopedData s la segent:
envelopedData version recipientInfo Version issuerAndSerialNumber keyEncryptionAlgorithm encryptedKey encryptedContentInfo Descripci Versi de lestndard que es fa servir. Conjunt de la informaci sobre els destinataris. Nhi ha dhaver com a mnim un. Versi de la sintaxi que es fa servir. Identifica el certificat del destinatari amb el nom de lautoritat de certificaci que lha ems i el nmero de srie del certificat. Algorisme de clau pblica utilitzat per a xifrar la clau de sessi. Clau de sessi xifrada. Contingut del missatge xifrat i informaci sobre el xifratge: tipus de contingut del missatge original i algorisme de xifratge utilitzat.
Com es veu, la informaci per a cada destinatari sagrupa en una estructura de tipus recipientInfo. Per a crear un sobre digital shan de seguir els passos segents: 1) Es genera de forma aleatria una clau de sessi per a un algorisme de xifratge simtric concret.
41
2) El contingut es xifra amb aquesta clau de sessi. 3) Per a cada destinatari, la clau de sessi es xifra amb la clau pblica del destinatari. 4) Per a cada destinatari, la clau de sessi xifrada i alguna informaci prpia del destinatari sagrupen en un valor del tipus recipientInfo. 5) Els valors del tipus recipientInfo un per a cada destinatari sajunten amb el contingut del missatge original per a crear el sobre digital. El procs que el receptor ha de seguir s: a) Desxifrar la clau de sessi que va dirigida al sobre digital i obrir-lo. b) Desxifrar el contingut del missatge amb la clau de sessi obtinguda en el pas anterior.
El xifratge duna informaci amb la tcnica del sobre digital es pot representar amb un PKCS#7 que contingui lobjecte envelopedData.
Exemple de lestructura dun PKCS#7 envelopedData
PKCS#7: SEQUENCE (308) contentType OBJECT IDENTIFIER (9) pkcs7-envelopedData content [0] TYPE (293) with SEQUENCE (289) version INTEGER (1) 0x00 (0) recipientInfos SET OF (230) SEQUENCE (227) version INTEGER (1) 0x00 (0) issuerAndSerialNumber SEQUENCE (76) issuer SEQUENCE OF (71) OU=Coyote Subordinate CA (MIR), O=UOC, C=ES serialNumber INTEGER (1) 0x24 (36) keyEncryptionAlgorithm SEQUENCE (13) algorithm OBJECT IDENTIFIER (9) pkcs1-rsaEncryption parameters TYPE (2) with NULL (0) encryptedKey OCTET STRING (128) 1892CA739A7DE62DCC... encryptedContentInfo SEQUENCE (51) contentType OBJECT IDENTIFIER (9) pkcs7-data contentEncryptionAlgorithm SEQUENCE (20) algorithm OBJECT IDENTIFIER (8) rsadsi-encryptionAlgorithm-des-ede3-cbc parameters TYPE (10) with OCTET STRING (8) A76D20B015138DF0 encryptedContent [0] IMPLICIT OCTET STRING (16) 7269AFD6A5DD...
6.1.4. Els signedAndEnvelopedData Lobjecte signedAndEnvelopedData consisteix en un sobre digital autenticat, s a dir, la informaci est xifrada amb la tcnica del sobre digital i, a ms, est signada. Les dades poden estar signades per un nombre qualsevol de signants en paral lel i, alhora, tot el contingut pot estar xifrat per un o ms destinataris.
42
La informaci que porta una estructura de dades signedAndEnvelopedData s la segent:

signedAndEnvelopedData version recipientInfos digestAlgorithms Descripci Versi de la sintaxi que es fa servir. Conjunt de la informaci sobre els destinataris. Nhi ha dhaver com a mnim un. Conjunt didentificadors dels algorismes de hash que shan fet servir per a crear les signatures digitals. Contingut del missatge xifrat i informaci sobre el xifratge: tipus de contingut del missatge original i algorisme de xifratge utilitzat. Cadena de certificaci des dels certificats utilitzats per la signatura fins als certificats de les autoritats de certificaci de nivell ms alt. Conjunt de llistes de certificats revocats. Conjunt dinformaci sobre els signants.
encryptedContentInfo
certificates crls signerinfo
Per a crear un sobre digital autenticat shan de seguir els passos segents:
1) Es genera una clau de sessi de manera aleatria amb algun algorisme de xifratge simtric.
2) El contingut del missatge es xifra amb aquesta clau de sessi.
3) Per a cada destinatari, la clau de sessi es xifra amb la clau pblica del destinatari.
4) Per a cada destinatari, la clau de sessi xifrada i alguna informaci prpia del destinatari sagrupa en un valor del tipus recipientInfo.
5) Per a cada signant, es calcula el resum del missatge amb lalgorisme que el signant desitgi; si dos signants fan servir el mateix algorisme, noms es calcula un cop.
6) Per a cada signant, el resum i altra informaci addicional es xifra amb la clau pblica prpia de cada signant, i desprs es xifra de nou amb la clau de sessi establerta.
7) Per a cada signant, el resum doblement xifrat sajunta amb altra informaci addicional del signant en una estructura de dades signerInfo.
8) Els resums del missatge de tots els signants, les estructures signerInfo i recipientInfo de tots els destinataris i signants sajunten amb el missatge xifrat en una estructura signedAndEnvelopedData.
43
El procs que el receptor ha de seguir per a processar la informaci s: a) Desxifrar la clau de sessi amb la clau privada prpia. b) Desxifrar el contingut del missatge, s a dir, la informaci dels signants i el propi missatge amb la clau de sessi. c) Desxifrar els resums, primer amb la clau de sessi i desprs amb la clau pblica de cada signant. d) Confrontar els resums obtinguts amb els calculats pel mateix destinatari utilitzant el mateix algorisme de hash. e) Llegir el missatge desxifrat.
6.1.5. Els digestedData
Lobjecte digestedData consisteix en qualsevol tipus de contingut i el seu resum corresponent. La finalitat daquest objecte s garantir la integritat del contingut i ser lentrada de processos de creaci dobjectes de tipus envelopedData.
La informaci que porta una estructura de dades digestedData s la segent:

digestedData version digestalgorithmid contentinfo digest Descripci Versi de la sintaxi que sest utilitzant. Identificador de lalgorisme de hash. Contingut a resumir. Resum del contingut.
El procs de creaci s el segent:
1) Es calcula un resum del contingut amb lalgorisme que es desitgi.
2) El contingut i el resum sagrupen en una estructura de tipus digestedData.
6.1.6. Els encryptedData Aquest objecte consisteix en qualsevol tipus de dades xifrades. No cont cap referncia al destinatari (pot ser que no nhi hagi) ni cap referncia a la clau que sha fet servir per a xifrar, que sassumeix que es gestiona des daltres mitjans. La finalitat s xifrar contingut localment; per aix, la clau de xifratge pot ser una simple contrasenya.
44
La informaci que porta una estructura de dades encryptedData s la segent:

encryptedData version encryptedContentInfo Descripci Versi de la sintaxi que es fa servir. Contingut xifrat.
6.2. El PKCS#10 El PKCS#10 descriu el format duna petici de certificat. Una petici de certificat consisteix en un nom, una clau pblica i un conjunt opcional datributs referents al subscriptor. Un dels atributs ms utilitzats s el duna contrasenya amb la qual el subscriptor podr revocar el certificat. Una petici est dividida en tres parts: la informaci de la petici, lidentificador de lalgorisme de signatura i la signatura digital de la informaci. La informaci de la petici sestructura en un camp certificationRequestInfo:
certificationRequestInfo version subject subjectPublicKeyInfo attributes Descripci Versi de la sintaxi que es fa servir. Nom distingit del propietari de la clau pblica. Informaci de la clau pblica. Conjunt datributs amb informaci addicional del subscriptor.
El procs que segueix lautoritat de certificaci en arribar-hi una petici consisteix a verificar la signatura i, en cas que sigui vlida, construir un certificat X.509 a partir del nom i la clau pblica que sindiquen a la petici. Les altres dades que inclour el certificat (nom de lemissor, nmero de srie, perode de validesa, identificador de lalgorisme de signatura, etc.) les determinar lautoritat de certificaci.
Exemple de lestructura dun PKCS#10
PKCS#10: SEQUENCE (478) toBeSigned SEQUENCE (327) version INTEGER (1) 0x00 (0) subject SEQUENCE OF (132) CN=user, OU=Criptografia, O=UOC, C=ES subjectPublicKeyInfo SEQUENCE (159) algorithm SEQUENCE (13) algorithm OBJECT IDENTIFIER (9) pkcs1-rsaEncryption parameters TYPE (2) with NULL (0) subjectPublicKey BIT STRING (141) Encapsulates TYPE (140) with rSAPublicKey SEQUENCE (137) modulus INTEGER (129) 0x00A1BA3CA9B379D12BD8C34F99D01A3AD3418A2... exponent INTEGER (3) 0x010001 (65537) attributes [0] IMPLICIT SET OF (25) SEQUENCE (23) attrType OBJECT IDENTIFIER (9) pkcs9-challengePassword attrValue TYPE (12) with SET OF (10) CHOICE (10) PrintableString (8) contrasenya signatureAlgorithm SEQUENCE (13) algorithm OBJECT IDENTIFIER (9) pkcs1-md5WithRSAEncryption parameters TYPE (2) with NULL (0) signature BIT STRING (129) 00 4936BDAD2A39E99EFC2125EDD99FCF15D3F9...
45
6.3. El PKCS#12
El PKCS#12 descriu una sintaxi per a la transferncia dinformaci didentitat personal, que pot incloure claus privades, certificats, ampliacions o altres secrets. Les aplicacions que admeten aquest format permeten lintercanvi segur de claus entre diversos repositoris.
El PKCS#12 permet la transferncia directa dinformaci personal sota diversos modes de confidencialitat i integritat. Hi ha quatre combinacions de modes de confidencialitat i dintegritat segons sutilitzin poltiques de clau pblica o de contrasenyes. Els modes privats xifraran la informaci personal per a protegir-la de lexposici pblica i els modes dintegritat garanteixen que la informaci no sigui falsificada.
Dins dels modes privats trobem:
a) Mode privat de clau pblica: la informaci personal sempaqueta i es xifra en la plataforma dorigen amb la clau pblica del dest.
b) Mode privat amb contrasenya: la informaci personal es xifra amb un nom dusuari i contrasenya.
Dins dels modes dintegritat hi ha:
a) Mode dintegritat de clau pblica: la integritat es garanteix mitjanant la signatura digital del contingut amb la clau privada de la plataforma dorigen. Aquesta forma es verificar en el dest.
b) Mode dintegritat amb contrasenya: la integritat es garanteix amb un codi dautenticaci del missatge MAC derivat de la contrasenya.
Lestndard permet la utilitzaci dels quatre modes, encara que des del punt de vista de la seguretat, el ms aconsellable s fer servir els modes de clau pblica, tant per a proporcionar privadesa com per a garantir la integritat. El parell de claus criptogrfiques de la plataforma utilitzades per al transport del PKCS#12 no shan de confondre amb les claus personals dusuari que es volen transportar dun dispositiu a un altre.
Daltra banda, no sempre s possible fer servir els modes de clau pblica per al transport segur de dades personals. Es pot donar el cas que en el moment de lexportaci dunes dades no sen conegui la plataforma de destinaci ni, per tant, la clau pblica. En aquests casos utilitzarem els modes de contrasenya.
s dels modes de contrasenya Els navegadors web importen i exporten certificats i claus privades amb un PKCS#12 de mode contrasenya.
46
La informaci del PKCS#12 sestructura de la manera segent:

PKCS#12 version authSafe Descripci Versi de la sintaxi que es fa servir. Estructura de dades PKCS#7 que t el format de signedData si sutilitza mode dintegritat de clau pblica o data si sutilitza mode dintegritat amb contrasenya. Camp opcional que hi s present si sutilitza mode dintegritat amb contrasenya. Estructura PKCS#7 digestData. Llavor aleatria per a fer el resum. Aquest camp no es fa servir; noms hi s per raons histriques.
macData mac macSalt iterations
El camp authSafe del PKCS#12 cont lembolcall de la informaci que es vol transferir. Est format per estructures de dades PKCS#7 que garanteixen la integritat i contenen, al seu torn, una altra estructura PKCS#7 ennierada amb la informaci xifrada de les dades per transportar. Els tipus de dades possibles per al PKCS#7 confidencial sn: data: si no fem servir el xifratge per a amagar les dades del PKCS#12. encryptedData: si utilitzem el xifratge per contrasenya. envelopedData: si emprem el xifratge per clau pblica. La informaci xifrada es crea a partir de la codificaci (data ), el xifratge (encryptedData) o lempaquetament (envelopedData) de les dades en clar disposades en una estructura anomenada safeContents. El safeContents est format per un conjunt de bosses segures (safeBags) que poden portar elements simples dinformaci (certificat, llistes de revocaci de certificats, clau privada, etc.). Les bosses segures disposen datributs opcionals perqu els usuaris puguin assignar un lies als seus objectes segurs i, daquesta manera, reconixer-los quan la informaci simporta dun entorn a un altre. Lestndard PKCS#12 sha implementat tant en programari com en maquinari i s el format ms utilitzat per a la transferncia de claus privades entre aplicacions.
Exemple de lestructura dun PKCS#12
PKCS#12: SEQUENCE (4403) version INTEGER (1) 0x03 (3) authSafes SEQUENCE (4337) contentType OBJECT IDENTIFIER (9) pkcs7-data content [0] TYPE (4322) with OCTET STRING (4318) 308210DA3082035406092A864886F70D010... macData SEQUENCE (57) mac SEQUENCE (33) digestAlgorithm SEQUENCE (9) algorithm OBJECT IDENTIFIER (5) secsig-algorithm-sha1 parameters TYPE (2) with NULL (0) digest OCTET STRING (20) 15A597AC8B967C00FFF8F846389C0... macSalt OCTET STRING (20) DC6D414C4732EDBD12FC10B4B69B... macIterationCount INTEGER (1) 0x01 (1) DEFAULT
47
7. Protocols que utilitzen infraestructura de clau pblica
Diversos protocols utilitzen la criptografia de clau pblica per a donar serveis de seguretat i, per tant, han de ser capaos de gestionar grans llistes de claus pbliques en sistemes distributs.
Les infraestructures de clau pblica sn la plataforma que els serveis de seguretat daquests protocols utilitzen per a fer lintercanvi de claus.
En aquest apartat veurem diferents protocols utilitzats en lactualitat que protegeixen els intercanvis de dades. Les aproximacions varien segons el nivell en qu es vol donar el servei: el nivell daplicaci (S/MIME, XML), el nivell de transport (TLS/SSL, SSH), el nivell de xarxa (IPsec) o el nivell fsic (caixes negres que xifren totes les dades que surten per un enlla).
7.1. IPsec El terme IPsec (IP Security Protocol) es refereix a un conjunt de mecanismes dissenyats per a protegir el trnsit en el nivell de xarxa IP (IPv4 o IPv6).
LIPsec ofereix els serveis de seguretat segents: integritat, autenticaci de les dades dorigen, protecci contra reenviaments i confidencialitat (confidencialitat de les dades i protecci parcial contra lanlisi de trnsit).
LIPsec utilitza els mecanismes AH i ESP per a proporcionar els seus serveis de seguretat: a) AH (authentication header) est concebut per a assegurar la integritat i lautenticaci dels datagrames IP sense tenir en compte el xifratge a les dades. Consisteix a afegir un camp addicional als datagrames IP tradicionals de manera que el receptor el pugui utilitzar per a verificar les dades incloses en el paquet. b) ESP (encapsulation security payload) est dissenyat per a assegurar la confidencialitat, per tamb pot proporcionar autenticitat a les dades. El principi de funcionament de lESP s generar un nou datagrama a partir del paquet IP original en el qual les dades, i eventualment la capalera, estiguin xifrades.
48
LIKE (Internet key exchange) s un protocol desenvolupat especficament per a IPsec amb lobjectiu de proporcionar mecanismes dintercanvi de claus i autenticaci. LIKE permet lintercanvi de claus de Diffie-Hellman i utilitza el model de PKI per a identificar i validar les claus criptogrfiques. A ms, tamb sutilitza la infraestructura de clau pblica en els mecanismes dautenticaci que inclouen signatures digitals. Com que lIPsec actua en el nivell de xarxa, tota la capa de seguretat que proporciona s completament transparent per a totes les aplicacions que lutilitzen. Els principals usos dIPsec sn: Connexi de dues xarxes privades distants a travs duna xarxa insegura com Internet. En aquest cas, sestableix una xarxa privada virtual (VPN) entre dues passarel les segures. Protecci de laccs a Internet per a usuaris externs, com usuaris mbils. La connexi IPsec es fa entre lusuari mbil i la passarel la daccs a Internet. Connexi extrem a extrem entre dos usuaris que no confien en la xarxa que els separa. Per cada mecanisme de seguretat dIPsec, hi ha dos modes de funcionament: 1) En el mode transport, noms es protegeixen les dades provinents del protocol del nivell superior i transportades per datagrames IP. Aquest mode noms el poden utilitzar els equips finals. 2) En el mode tnel, la capalera IP tamb es protegeix (autenticaci, integritat i/o confidencialitat). La capalera nova es reemplaa altra vegada al final del tnel per lautoritat de la capalera original. El mode tnel el fan servir equips finals i passarel les segures, i permet protegir lenlla de lanlisi de trnsit.
7.2. SSL
LSSL (secure sockets layer) s un protocol, originalment desenvolupat per Netscape i mpliament acceptat per la comunitat Internet, que ofereix comunicacions confidencials i autntiques entre un client i un servidor.
LSSL corre sobre el nivell de transport TCP/IP i per sota de protocols com HTTP o IMAP. Est format per dos subprotocols: Protocol de registre: defineix el format utilitzat per a la transmissi de dades.
HTTP Sanomena HTTPS la utilitzaci dHTTP sobre SSL.
49
Protocol destabliment: defineix lintercanvi de missatges entre client i servidor perqu estableixin un context segur de comunicaci. El protocol destabliment facilita les accions segents: Autenticaci mtua de client i/o servidor. Selecci dels algorismes criptogrfics i xifres que tant client com servidor suporten. Generaci de secrets compartits. Establiment duna connexi SSL xifrada. LSSL utilitza la infraestructura de clau pblica fonamentalment per a autenticar les entitats durant lestabliment de la connexi. Tant el client com el servidor disposen dun parell de claus criptogrfiques que utilitzen per a signar unes dades aleatries. Les dades, la signatura i el certificat corresponent a la clau privada utilitzada (i, opcionalment, tota la cadena de certificats fins al certificat de lautoritat de certificaci arrel) senvien a laltra entitat perqu en verifiqui la signatura. La verificaci de la signatura ha de tenir en compte que la cadena de certificats sigui vlida i que cap daquests certificats estigui contingut en una llista de revocaci. Si la verificaci s correcta, lentitat pot assegurar la identitat de linterlocutor.
7.3. S/MIME
LS/MIME (secure multipurpose Internet mail extensions) s una especificaci de correu electrnic segur dissenyada per a afegir serveis dautenticaci, integritat, no-repudi dorigen i confidencialitat als missatges electrnics basats en el format estndard dInternet MIME.
LS/MIME adopta les normes i formats definits en el PKCS#7, de manera que la seva integraci en les aplicacions de correu electrnic s relativament senzilla. Les dades que es volen protegir tenen lestructura duna entitat MIME; els objectes segurs PKCS que resulten desprs del procs criptogrfic sincrusten en el missatge de correu electrnic per mitj dun embolcall MIME. S/MIME ofereix formats per a sobres digitals, signatures digitals i sobres digitals autenticats.
7.4. Seguretat en XML LXML (extensible mark-up language) s una especificaci desenvolupada pel World Wide Web Consortium (W3C) que defineix una sintaxi i unes regles sobre ls detiquetes per a estructurar la informaci.
50
Els estndards de seguretat XML defineixen el vocabulari i les regles de processament necessries per a oferir serveis de seguretat a les noves tecnologies que utilitzen aquest llenguatge.
Les caracterstiques dels estndards XML sn: Estan dissenyats per a oferir la flexibilitat i ampliabilitat prpies dXML. Permeten que la seguretat sapliqui a documents XML, elements XML, noms al contingut dun element, o b en documents binaris arbitraris. La seguretat saplica extrem a extrem, ja que est associada al contingut i no pas al canal de transport. Es reutilitzen les tecnologies de seguretat existents a tot arreu on sigui possible. Per exemple, sutilitzen certificats X.509 que, en aquest cas, es codifiquen en format text. Els estndards bsics de la seguretat XML sn els segents: XML Signature (XMLDsig): defineix mecanismes per a suportar la creaci i verificaci de signatures digitals sobre documents XML. XML Encryption (XMLEnc): ofereix solucions de confidencialitat. s una especificaci anloga a lobjecte envelopedData del PKCS#7, amb la particularitat que la confidencialitat es pot aplicar amb gran nivell de granularitat sobre el document XML. Aquesta caracterstica permet xifrar porcions de missatges de protocols XML que han de ser encaminats per processadors intermedis. XML Key Management (XKMS): defineix protocols per a la gesti de claus pbliques (registre, revocaci, localitzaci i validaci). Permet que els usuaris administrin els seus certificats dinfraestructura de clau pblica sense que hagin de conixer-ne la tecnologia. Security Assertion Markup Language (SAML): especifica un vocabulari per a compartir asseveracions dautenticaci i autoritzaci entre diferents entitats independents i, daquesta manera, permet els serveis denregistrament nic (single sign-on, SSO). XML Access Control Markup Language (XACML): defineix un vocabulari per a expressar condicions i regles dautoritzaci.
Per a obtenir ms informaci sobre els estndards XML, podeu consultar el portal de World Wide Web Consortium: http://www.w3c.org
51
Resum
En aquest mdul hem descrit el funcionament duna infraestructura de clau pblica i hem vist les estructures de dades i els protocols que utilitzen aquesta tecnologia. Els aspectes que hem tractat sn els segents: 1) Hem estudiat els components que formen una infraestructura de clau pblica per tal dentendre quins serveis ens ofereix. 2) Hem fet referncia als models de confiana i hem vist com sestablien les relacions de confiana entre entitats dun mateix grup i entre diferents organitzacions. 3) Hem descrit els processos associats al cicle de vida de les claus criptogrfiques i dels certificats. 4) Hem detallat les caracterstiques de lelement principal de la infraestructura de clau pblica: el certificat digital. Hem vist com estan estructurades les dades del certificat i com es pot ampliar la informaci que shi cont per tal dadaptar-lo a futures necessitats. 5) Hem explicat el format dels missatges PKCS que porten informaci associada a serveis de seguretat. 6) Finalment, hem fet referncia a protocols de xarxa, transport i presentaci que utilitzen la infraestructura de clau pblica per a donar serveis de seguretat.
53
Activitats
1. FESTE s una autoritat de certificaci espanyola en qu participen, entre altres, notaris i corredors de comer. Busqueu quines sn les poltiques de certificaci (CP) dels certificats que emet i quina s la declaraci de prctiques de certificaci (CPS). 2. Visiteu la pgina web http://www.openvalidation.org i proveu la funcionalitat dels serveis dOCSP amb el vostre navegador. 3. Ceres s una autoritat de certificaci que ofereix els seus serveis perqu lFNMT (Fbrica Nacional de Moneda i Timbre) pugui proporcionar certificats digitals a tots els ciutadans espanyols per a la resoluci via Internet dalgunes gestions amb lAgncia Tributria (per exemple, la declaraci de renda). A partir de la seva pgina principal, http://www.cert.fnmt.es, seguiu tots els passos necessaris per a lobtenci dun certificat digital. 4. Segons hem vist, els navegadors web fan servir un model per llista de confiana. Cerqueu dins els navegadors que utilitzeu habitualment on est aquesta llista i en quines autoritats de certificaci arrel confieu quan navegueu per Internet. Mireu si s possible afegir o eliminar autoritats de certificaci daquesta llista.
Vegeu el model per llista de confiana en el subapartat 3.4 daquest mdul.
Exercicis dautoavaluaci
1. Cal comprovar les llistes de revocaci de certificats per a saber si un certificat ha caducat? 2. Volem recuperar la clau de signatura dun usuari de la nostra empresa que sha jubilat. s possible que la CPS ho permeti? 3. Indiqueu els passos que cal seguir per a verificar la signatura digital duna estructura PKCS#7. 4. Els PKCS sn estructures de dades que porten informaci criptogrfica. Feu una taula que indiqui en quins PKCS podeu trobar una clau pblica, una clau privada o una clau simtrica. 5. El perfil de certificat X.509 especificat per PKIX defineix una ampliaci extKeyUsage per a indicar les aplicacions a les quals es dirigeix ls del certificat. Llisteu el valor que aquesta ampliaci pot prendre i la relaci que t amb lampliaci keyUsage. 6. El certificat duna autoritat de certificaci expira al final del 2005. Aquesta autoritat de certificaci emet certificats de signatura digital amb una validesa de dos anys. Fins a quina data podr emetre certificats? Fins quan ha de continuar donant serveis lautoritat de certificaci? 7. Quines operacions es poden fer amb un parell de claus criptogrfiques quan el certificat de xifratge corresponent ha expirat? 8. Llisteu totes les autoritats de certificaci possibles per les quals una aplicaci pugui considerar invlid un certificat.
54
Solucionari
1. La informaci sobre la data dexpiraci dun certificat no cal buscar-la en les llistes de revocaci de certificats, ja que es pot trobar en el mateix certificat, dins del camp validity. 2. Les CPS no permeten la recuperaci de claus de signatura per dos motius. Duna banda, no t sentit tenir-ne cpies de seguretat, ja que la prdua duna clau de signatura no suposa cap inconvenient per a interactuar amb dades signades amb anterioritat. Daltra banda, el fet de tenir una cpia de la clau privada impediria que es pogus utilitzar en serveis de no-repudi. 3. Els passos que cal seguir per a verificar la signatura dun PKCS#7 sn: a) Desxifrar els resums de cada signant amb la clau pblica daquest. b) Comparar que els resums coincideixen amb els que sobtenen en fer els clculs amb les dades que sautentiquen. 4. PKCS en qu es pot trobar una clau pblica, una clau privada o una clau simtrica: PKCS 7 8 10 12 x x x Clau pblica x x Clau privada Clau simtrica x
5. Els usos definits en el perfil de PKIX per a lampliaci extKeyUsage sn els segents: extKeyUsage serverAuth Autenticaci de servidor clientAuth Autenticaci de client Descripci Es fa servir per a lautenticaci del servidor en TLS Es fa servir per a lautenticaci del client en TLS Es fa servir per a signar codi descarregable. s necessria per a utilitzar authenticode (ActiveX, applets de Java, javascripts, etc.) Permet ls per a protegir missatges de correu electrnic Permet ls per a enllaar el hash dun objecte a un temps provinent duna font de temps acordada. Valors de keyUsage digitalSignature, keyEncipherment o keyAgreement digitalSignature i/o keyAgreement
codeSigning Signatura de codi
digitalSignature
emailProtection Protecci de correu electrnic timeStamping Segellat de temps
digitalSignature, nonRepudation i/o keyEncipherment o keyAgreement. digitalSignature i nonRepudiation
6. Els certificats que emet una autoritat de certificaci noms tenen validesa dins el perode de validesa del mateix certificat de lautoritat de certificaci. Com que lautoritat de certificaci expira al final del 2005 i emet certificats amb una validesa de dos anys, lautoritat de certificaci haur de deixar dexpedir certificats al final del 2003. Els certificats de lautoritat de certificaci sn vlids fins al final del 2005, i fins a aquesta data lautoritat de certificaci haur de continuar oferint serveis als seus clients, si b no per a lexpedici de nous certificats, sin per tal de poder tractar casos com la revocaci de certificats emesos. 7. Si el certificat de xifratge expira, la clau pblica no es pot utilitzar per a xifrar ms dades. En aquest cas, el perode dexpiraci del certificat limita la vida til de xifratge de la clau pblica. Daltra banda, la clau privada s que es podr fer servir ms enll de la data de caducitat del certificat: el titular de la clau la podr utilitzar per a desxifrar informaci xifrada quan el certificat encara era vlid.
55
8. Les condicions que poden fer que un certificat es consideri invlid (i per tant, que caldria comprovar si fssim una aplicaci basada en certificats) sn: El certificat ha caducat. La signatura digital del certificat s criptogrficament invlida. Lautoritat de certificaci que ha generat el certificat no s de la nostra confiana. El certificat ha estat revocat. Hi ha una ampliaci crtica no reconeguda per laplicaci.
Glossari
autoritat de certificaci f Autoritat de confiana que emet certificats. sigla: CA autoritat de registre f Entitat que sencarrega de les tasques ms administratives de lautoritat de certificaci, com ara la confirmaci de la identitat dels usuaris, la verificaci que lusuari posseeix la clau privada associada a la clau pblica que es vol certificar, la publicaci dels certificats en directoris, etc. sigla: RA autoritat de segellat de temps f Autoritat que proporciona una prova dexistncia de certes dades abans dun instant de temps determinat. sigla: TSA autoritat de validaci f Autoritat que proporciona informaci sobre lestat de revocaci dels certificats. sigla: VA CA f Vegeu autoritat de certificaci. certificat digital m Estructura de dades que vincula una identitat amb una clau pblica. El certificat s ems per una autoritat de certificaci. CP f Vegeu poltica de certificats. CPS f Vegeu declaraci de les prctiques de certificaci. CRL f Vegeu llista de revocaci de certificats. declaraci de les prctiques de certificaci f Declaraci de les prctiques que una autoritat de certificaci utilitza per a emetre certificats. sigla: CPS entitat final f Propietari dun certificat que no s una autoritat de certificaci. LDAP m Acrnim de light weight directory access protocol. Protocol daccs a un directori. llista de revocaci de certificats f Llista emesa per les autoritats de certificaci en la que es publiquen tots aquells certificats que han estat revocats. sigla: CRL OCSP m Acrnim donline certificate status protocol. Protocol per a determinar lestat de revocaci dun certificat. PKCS m Acrnim de public-key cryptography standards. Conjunt despecificacions desenvolupades en els laboratoris RSA per tal destablir una norma comuna a la indstria sobre els formats de les dades utilitzades en criptografia de clau pblica. PKI f Acrnim de public key infrastructure. Conjunt de maquinari, programari, persones, poltiques i procediments necessaris per a crear i gestionar certificats digitals basats en criptografia de clau pblica. poltica de certificats f Conjunt de normes que indiquen laplicabilitat dun certificat a una aplicaci o comunitat. sigla: CP RA f Vegeu autoritat de registre.
56
SCVP m Acrnim de simple certificate validation protocol. Protocol per a determinar la ruta de certificaci dun certificat i el seu lestat de revocaci. TSA f Vegeu autoritat de segellat de temps. VA f Vegeu autoritat de validaci. XML m Acrnim de lexpressi anglesa extensible mark-up language. Especificaci que defineix una sintaxi i unes regles sobre ls detiquetes per a estructurar la informaci.
Bibliografia
Nash, Andrew; Duancem, Joseph; Brink, James E. (2001). PKI implementing and managing e-security. Nova York (etc.): Osborne / McGraw-Hill. Adams, Carlisle; Lloyd, Steve (2003). Understanding PKI (2a. ed.). Boston: Addison-Wesley. IETF-PKIX Working Group. Public-Key Infrastructure (X.509). <http://www.ietf.org/html.charters/pkix-charter.html> RSA Security. PKCS: Public Key Criptography Standards. <http://www.rsasecurity.com/rsalabs/pkcs/> World Wide Web Consortium (W3C). XML encryption syntax and processing. <http://www.w3.org>

M7 - Infraest Clau Pub

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

M7 - Infraest Clau Pub

Uploaded by

Copyright:

Available Formats

Infraestructura de clau pblica

Universitat Oberta de Catalunya P03/05024/02265

Infraestructura de clau pblica

Universitat Oberta de Catalunya P03/05024/02265

Infraestructura de clau pblica

Universitat Oberta de Catalunya P03/05024/02265

Infraestructura de clau pblica

Universitat Oberta de Catalunya P03/05024/02265

Infraestructura de clau pblica

Universitat Oberta de Catalunya P03/05024/02265

Infraestructura de clau pblica

Universitat Oberta de Catalunya P03/05024/02265

Infraestructura de clau pblica

Universitat Oberta de Catalunya P03/05024/02265

Infraestructura de clau pblica

* En angls, public key infrastructure.

Universitat Oberta de Catalunya P03/05024/02265

Infraestructura de clau pblica

Universitat Oberta de Catalunya P03/05024/02265

Infraestructura de clau pblica

2. Components duna infraestructura de clau pblica

2.1. Autoritat de certificaci

* En angls, certification authority.

Universitat Oberta de Catalunya P03/05024/02265

Infraestructura de clau pblica

2.2. Autoritat de registre

* En angls, registration authority.

2.3. Subscriptors i entitats finals

Universitat Oberta de Catalunya P03/05024/02265

Infraestructura de clau pblica

* En angls, certification revocation list.

Universitat Oberta de Catalunya P03/05024/02265

Infraestructura de clau pblica

* En angls, distinguished name.

2.6. Autoritat de validaci

Lautoritat de validaci* (VA) s lencarregada de comprovar la validesa dels certificats digitals.

* En angls, validation authority.

Universitat Oberta de Catalunya P03/05024/02265

Infraestructura de clau pblica

2.6.1. Online certificate status protocol (OCSP)

2.6.2. Simple certificate validation protocol (SCVP)

Universitat Oberta de Catalunya P03/05024/02265

Infraestructura de clau pblica

2.7. Autoritat de segellat de temps

Universitat Oberta de Catalunya P03/05024/02265

Infraestructura de clau pblica

Universitat Oberta de Catalunya P03/05024/02265

Infraestructura de clau pblica

Universitat Oberta de Catalunya P03/05024/02265

Infraestructura de clau pblica

Universitat Oberta de Catalunya P03/05024/02265

Infraestructura de clau pblica

Universitat Oberta de Catalunya P03/05024/02265

Infraestructura de clau pblica

Universitat Oberta de Catalunya P03/05024/02265

Infraestructura de clau pblica

b) Per a la interconnexi de cent infraestructures de clau pblica:

Universitat Oberta de Catalunya P03/05024/02265

Infraestructura de clau pblica

Vegeu el model jerrquic en el subapartat 3.3 daquest mdul.

Universitat Oberta de Catalunya P03/05024/02265

Infraestructura de clau pblica

4. Cicle de vida de claus i certificats digitals

Universitat Oberta de Catalunya P03/05024/02265