Vés al contingut

Protocol de contrasenya remota segura

De la Viquipèdia, l'enciclopèdia lliure

El protocol Secure Remote Password (SRP) és un protocol d'intercanvi de claus autenticades per contrasenya augmentat (PAKE), dissenyat específicament per funcionar al voltant de les patents existents.[1]

Com tots els protocols PAKE, un escoltador o un intermediari no pot obtenir prou informació per poder endevinar una contrasenya per força bruta o aplicar un atac de diccionari sense més interaccions amb les parts per a cada endevinació. A més, en ser un protocol PAKE augmentat, el servidor no emmagatzema dades equivalents a la contrasenya.[2] Això significa que un atacant que robi les dades del servidor no es pot fer passar per client tret que primer realitzi una cerca per força bruta de la contrasenya.

En termes senzills, durant l'autenticació SRP (o qualsevol altre protocol PAKE), una part (el "client" o "usuari") demostra a una altra part (el "servidor") que coneix la contrasenya, sense enviar la contrasenya en si ni cap altra informació de la qual es pugui derivar la contrasenya. La contrasenya mai surt del client i és desconeguda per al servidor.

A més, el servidor també necessita saber la contrasenya (però no la contrasenya en si) per tal d'iniciar la connexió segura. Això significa que el servidor també s'autentica davant del client, cosa que evita el phishing sense dependre que l'usuari analitzi URL complexes.

L'única propietat de seguretat matemàticament provada de SRP és que és equivalent a Diffie-Hellman contra un atacant passiu.[3] Tot i que és madur i àmpliament implementat, SRP és un disseny més antic amb algunes variants que mostren debilitats subtils; no és segur per a la UC, no té resistència a tots els atacs de precomputació, té proves formals més febles i no ofereix cap protecció contra certs models d'atac moderns. Per aquestes raons, SRP ara es considera en gran mesura superat. OPAQUE és el PAKE augmentat preferit, mentre que CPace o SPAKE2 són els preferits per a escenaris de PAKE equilibrats on ambdues parts comparteixen la contrasenya.[4][5]

Visió general

[modifica]

El protocol SRP té diverses propietats desitjables: permet a un usuari autenticar-se a un servidor, és resistent als atacs de diccionari realitzats per un escoltador i no requereix un tercer de confiança. Transmet eficaçment una prova de contrasenya de coneixement zero de l'usuari al servidor. A la revisió 6 del protocol només es pot endevinar una contrasenya per intent de connexió. Una de les propietats interessants del protocol és que, fins i tot si s'ataca una o dues de les primitives criptogràfiques que utilitza, continua sent segur. El protocol SRP s'ha revisat diverses vegades i actualment es troba a la revisió 6a.

El protocol SRP crea una clau privada gran compartida entre les dues parts de manera similar a l'intercanvi de claus Diffie-Hellman, basat en què el costat del client té la contrasenya de l'usuari i el costat del servidor té un verificador criptogràfic derivat de la contrasenya. La clau pública compartida es deriva de dos nombres aleatoris, un generat pel client i l'altre generat pel servidor, que són únics per a l'intent d'inici de sessió. En els casos en què es requereixen comunicacions xifrades i autenticació, el protocol SRP és més segur que el protocol SSH alternatiu i més ràpid que l'ús de l'intercanvi de claus Diffie-Hellman amb missatges signats. També és independent de tercers, a diferència de Kerberos.

El protocol SRP, versió 3, es descriu a RFC 2945. La versió 6a de SRP també s'utilitza per a l'autenticació de contrasenya forta en SSL/TLS[6] (en TLS-SRP) i altres estàndards com ara EAP[7] i SAML, i forma part de IEEE 1363.2 i ISO/IEC 11770-4.

Protocol

[modifica]

En aquesta descripció del protocol, versió 6, s'utilitza la notació següent:

  • q i N = 2 q + 1 es trien de manera que tots dos siguin primers (cosa que fa que q sigui un nombre primer de Sophie Germain i N un nombre primer segur). N ha de ser prou gran perquè el càlcul de logaritmes discrets mòdul N sigui inviable.
  • Tota l'aritmètica es realitza en l' anell d'enters mòdul N, Això significa que per sota de g x s'ha de llegir com a g x mod N
  • g és un generador del grup multiplicatiu .
  • H () és una funció hash; per exemple, SHA-256.
  • k és un paràmetre derivat per ambdós costats; a SRP-6, k = 3, mentre que a SRP-6a es deriva de N i g: k = H (N, g). S'utilitza per evitar una conjectura de 2 per 1 quan un atacant actiu suplanta el servidor.[8]
  • s és una sal.
  • I és un nom d'usuari identificatiu.
  • p és la contrasenya de l'usuari.
  • v és el verificador de contrasenya de l'amfitrió, v = g x on com a mínim x = H (s, p). Com que x només es calcula al client, és lliure de triar un algorisme més fort. Una implementació podria optar per utilitzar x = H(s | I | p) sense afectar cap pas requerit per l'amfitrió. L'estàndard RFC2945 defineix x = H(s | H ( I | ":" | p) ). L'ús d' I dins de x evita que un servidor maliciós pugui saber si dos usuaris comparteixen la mateixa contrasenya.
  • A i B són claus efímeres aleatòries d'un sol ús de l'usuari i l'amfitrió, respectivament.
  • | (pipe) denota concatenació.

Totes les altres variables es defineixen en termes d'aquestes.

Primer, per establir una contrasenya p amb el servidor Steve, la clienta Carol tria una sal aleatòria s i calcula x = H (s, p), v = gxx Steve emmagatzema v i s, indexats per I, com a verificador de contrasenya i salt de Carol. Carol no ha de compartir x amb ningú i l'ha d'esborrar de manera segura en aquest pas, perquè és equivalent a la contrasenya de text pla p. Aquest pas es completa abans que el sistema s'utilitzi com a part del registre d'usuari amb Steve. Tingueu en compte que la salt s es comparteix i s'intercanvia per negociar una clau de sessió més tard, de manera que el valor pot ser triat per qualsevol dels dos costats, però ho fa Carol perquè pugui registrar I, s i v en una única sol·licitud de registre. La transmissió i l'autenticació de la sol·licitud de registre no estan cobertes a SRP.

Aleshores, per dur a terme una prova de contrasenya més endavant, es duu a terme el següent protocol d'intercanvi:

  1. Carol → Steve: genera un valor aleatori a; envia I i A = ga
  2. Steve → Carol: genera un valor aleatori b; envia s i B = kv + gb
  3. Ambdues: u = H (A, B)
  4. Carol: S Carol = (B − kgx )(a + ux )x ( kv + gbb) (a + ux) = (kgxxkgxxgb)(a + ux)b)(a + ux)
  5. Carol: K Carol = H (SCarol)
  6. Steve: S Steve = (Avu)b = (gava)b = [ga(gxx]b = (ga+ux)b = (gba(u+b)
  7. Steve: K Steve = H (SSteve) = K Carol

Ara les dues parts tenen una clau de sessió compartida i forta K. Per completar l'autenticació, han de demostrar-se mútuament que les seves claus coincideixen. Una possible manera és la següent:

  1. Carol → Steve: M1 = H[H(N) XOR H(g) | H(I) | s | A | B | KCarol]. Steve verifica M1.
  2. Steve → Carol: M2 = H(A | M1 | KSteve). La Carol verifica M2.

Aquest mètode requereix endevinar més informació de l'estat compartit per tenir èxit en la suplantació d'identitat que només la clau. Tot i que la major part de l'estat addicional és públic, es podria afegir informació privada amb seguretat a les entrades de la funció hash, com ara la clau privada del servidor.

Alternativament, en una demostració només amb contrasenya, es pot ometre el càlcul de K i demostrar la S compartida amb:

  1. Carol → Steve: M1 = H(A | B | SCarol). Steve verifica M1.
  2. Steve → Carol: M2 = H(A | M1 | SSteve). La Carol verifica M2.

Quan s'utilitza SRP per negociar una clau compartida K que s'utilitzarà immediatament després de la negociació, és temptador ometre els passos de verificació d' M1 i M2. El servidor rebutjarà la primera sol·licitud del client que no pot desxifrar. Tanmateix , això pot ser perillós , tal com es demostra a la secció Trampes d'implementació a continuació.

Les dues parts també utilitzen les següents garanties:

  1. La Carol avortarà si rep B = 0 (mod N) o u = 0.
  2. L'Steve avortarà si rep A (mod N ) = 0.
  3. La Carol ha de mostrar primer la seva demostració de K (o S). Si l'Esteve detecta que la demostració de la Carol és incorrecta, ha d'avortar sense mostrar la seva pròpia demostració de K (o S ).

Història

[modifica]

El projecte SRP es va iniciar el 1997.[9] Dos enfocaments diferents per solucionar un forat de seguretat a SRP-1 van donar lloc a SRP-2 i SRP-3.[10] SRP-3 es va publicar per primera vegada el 1998 en una conferència.[11] RFC 2945, que descriu SRP-3 amb SHA1, es va publicar el 2000.[12] SRP-6, que corregeix atacs d'endevinació i ordenació de missatges "dos per un", es va publicar el 2002. SRP-6a va aparèixer a la "libsrp" oficial a la versió 2.1.0, de 2005.[13] SRP-6a es troba als estàndards com:

  • ISO/IEC 11770-4:2006 "Mecanisme d'acord clau 2" (anomena el mètode "SRP-6, però té el càlcul k de 6a)
  • RFC 5054 TLS-SRP del 2007 (de nou anomenada "SRP-6", però corregida a l'errata[14])
  • IEEE Std 1363.2-2008 "DLAPKAS-SRP6" (de nou anomenada "SRP-6")[15]

L'IEEE 1363.2 també inclou una descripció de "SRP5", una variant que substitueix el logaritme discret per una corba el·líptica aportada per Yongge Wang el 2001.[16] També descriu SRP-3 tal com es troba a RFC 2945.

Referències

[modifica]
  1. ↑ «What is SRP?» (en anglès). Stanford University.
  2. ↑ Sherman, Alan T.; Lanus, Erin & Liskov, Moses et al. (2020), Nigam, Vivek; Ban Kirigin, Tajana & Talcott, Carolyn et al., eds., Formal Methods Analysis of the Secure Remote Password Protocol, Lecture Notes in Computer Science, Cham: Springer International Publishing, pàg. 103–126, ISBN 978-3-030-62077-6, DOI 10.1007/978-3-030-62077-6_9
  3. ↑ Green, Matthew. «Should you use SRP?» (en anglès). A Few Thoughts on Cryptographic Engineering, 18-10-2018. NB: source refers to SRP-6 as SRPv4 for reason unknown.
  4. ↑ Abdalla, Michel; Haase, Björn & Hesse, Julia (2025-04-16), CPace, a balanced composable PAKE, IETF, I-D draft-irtf-cfrg-cpace-14, <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-cpace-14>. Consulta: 15 setembre 2025
  5. ↑ «Results of the PAKE selection process» (PDF) (en anglès). Crypto Forum Research Group of the Internet Research Task Force (IRTF CFRG), 01-04-2020. [Consulta: 15 setembre 2025].
  6. ↑ Taylor, David. «Using the Secure Remote Password (SRP) Protocol for TLS Authentication», 01-11-2007. RFC 5054
  7. ↑ Carlson, James. «EAP SRP-SHA1 Authentication Protocol». IETF, 01-07-2001. Draft.
  8. ↑ «SRP Protocol Design» (en anglès).
  9. ↑ «SRP: About the Project» (en anglès). srp.stanford.edu.
  10. ↑ «SRP-2: Design Specifications» (en anglès). srp.stanford.edu.
  11. ↑ Wu, T., "The Secure Remote Password Protocol", Proceedings of the 1998 Internet Society Network and Distributed System Security Symposium pp. 97-111, March 1998.
  12. ↑ «SRP: Design Specifications» (en anglès). srp.stanford.edu.
  13. ↑ CHANGES file in srp-2.1.2.tar.gz, available from http://srp.stanford.edu/download.html
  14. ↑ Wang, Mingye. «RFC Errata Report #7538» (en anglès). RFC Editor. [Consulta: 15 octubre 2023].
  15. ↑ IEEE 1363.2-2008: IEEE Standard Specification for Password-Based Public-Key Cryptographic Techniques
  16. ↑ Wang, Y., "IEEE P1363.2 Submission / D2001-06-21," [P1363.2-ecsrp-06-21.doc] A contribution by Yongge Wang for P1363.2 giving an elliptic curve version of the SRP protocol, June 21, 2001.
Obtingut de «https://ca.wikipedia.org/w/index.php?title=Protocol_de_contrasenya_remota_segura&oldid=37345642»