{"id":292,"date":"2018-12-16T12:55:41","date_gmt":"2018-12-16T12:55:41","guid":{"rendered":"http:\/\/nitk.acm.org\/blog\/?p=292"},"modified":"2018-12-16T12:55:41","modified_gmt":"2018-12-16T12:55:41","slug":"strengthening-security-with-pake-protocol","status":"publish","type":"post","link":"https:\/\/nitk.acm.org\/blog\/2018\/12\/16\/strengthening-security-with-pake-protocol\/","title":{"rendered":"Strengthening Security with PAKE Protocol"},"content":{"rendered":"

You know that guy who does a lot of work but just doesn\u2019t get the attention he deserves? The PAKE Protocol is that guy. <\/span><\/p>\n

PAKE – One of the most efficient cryptographic protocols ever drafted yet rarely gets used.<\/span><\/p>\n

NOTE : Throughout this article, there might be words you have never heard of. I have tried explaining most of them in braces[] and in italics.<\/span><\/i><\/p>\n

PAKE stands for Password Authenticated Key Exchange. <\/b><\/p>\n

Let us consider a simple problem where there is a server which stores user passwords. <\/span>The traditional way to do this is to hash [<\/span>A cryptographic hash function is a hash function which takes an input and returns a fixed-size alphanumeric string<\/span><\/i>] each user password and store the result in a database. But there exists a drawback : <\/span>When the user comes back to log into the website, they will still need to send over their (cleartext) password, since this is required in order for the server to do the check. <\/i><\/b><\/p>\n

The fact that the cleartext password <\/span>has<\/b> to reach the server poses a major threat if the server is compromised. Hence, there is a need to introduce a new method to ensure that the cleartext password doesn\u2019t reach the server. <\/span><\/p>\n

PAKE as the name suggests is a key exchange mechanism. Key exchange protocols are designed to help two parties (say a <\/span>client<\/span><\/i> and <\/span>server<\/span><\/i>) agree on a shared key, using public-key cryptography. Some key exchange protocols \u2014 like the Diffie-Hellman were unauthenticated, which made them vulnerable to man-in-the-middle attacks <\/span>[Attacks where the attacker secretly relays and possibly alters the communication between two parties who believe they are directly communicating with each other]<\/span><\/i>. The distinguishing feature of PAKE protocols is the client will authenticate herself to the server using a password. <\/span><\/p>\n

PAKE provides protection for the client\u2019s password. After a login attempt (valid, or invalid) both the client and server should learn <\/span>only<\/b> whether the client\u2019s password matched the server\u2019s expected value, and <\/span>no<\/b> additional information. <\/span><\/p>\n

\"\"<\/p>\n

Ideal representation of the PAKE protocol<\/span><\/i><\/p>\n

Why isn\u2019t PAKE being adopted?<\/b><\/h2>\n

With the exception of SRP(explained below), which is a varied version of the PAKE protocol, there seems to be no sight of the PAKE anywhere else. <\/span><\/p>\n

Possible reasons : <\/span><\/p>\n

    \n
  1. There\u2019s a lack of good PAKE implementations in useful languages, which makes it a hassle to use. <\/span><\/li>\n
  2. Patents hinder its implementation.<\/span><\/li>\n
  3. PAKE is not officially a certified protocol and many people aren\u2019t aware of it.<\/span><\/li>\n<\/ol>\n

    OPAQUE<\/b><\/h2>\n

    There is a certain protocol called the SRP<\/span> [<\/span>Secure Remote Password<\/span><\/i>]<\/span> protocol, which is a varied version of the PAKE protocol. It is one of the widely used protocols right now. SRP has been declared as an industry standard, and is actually implemented in libraries like OpenSSL. <\/span><\/p>\n

    But SRP has its drawbacks. SRP is vulnerable to pre-computation attacks, because it hands over the user\u2019s \u201csalt\u201d <\/span>[In cryptography, a salt is random data that is used as an additional input to a one-way function that “hashes” data. A new salt is randomly generated for each password]<\/span><\/i> to an attacker who can start an SRP session. This means the attacker can ask a server for your salt, and build a dictionary of potential password hashes even <\/span>before<\/span><\/i> the server is compromised (hence the term, pre-computation). <\/span><\/p>\n

    OPAQUE solves this scenario. The protocol might be too complex to explain in a single article. But its features and functionality advantages can be easily studied.<\/span><\/p>\n

    OPAQUE does <\/span>not<\/span><\/i> reveal the salt to the attacker. It solves this problem by using an efficient oblivious<\/span> PRF<\/i><\/b> [A Pseudo Random Function is a function that is indistinguishable from a function selected at random from the set of all functions with the same domain and value set.] to combine the salt with the password, in a way that ensures the client does not learn the salt <\/span>and<\/span><\/i> the server does not learn the password. OPAQUE works with <\/span>any<\/span><\/i> password hashing function. Since all the hashing work is done on the <\/span>client<\/span><\/i>, OPAQUE can actually <\/span>take load off<\/span><\/i> the server.<\/span><\/p>\n

    How OPAQUE works<\/b><\/h2>\n

    Keeps the salt a secret <\/i><\/b><\/h3>\n

    The salt, along with the password is fed into a hash function. If the server is the one that computes this function, then the server has to see the password and the purpose is destroyed. Meanwhile, if it\u2019s the client, the client needs the salt, which again defeats the purpose. <\/span><\/p>\n

    To solve this, OPAQUE does the following. The protocol leaves the password has on the client\u2019s side, but doesn\u2019t provide the salt to the hash. Instead, a special two-party protocol called an oblivious <\/span>PRF<\/b> (mentioned earlier) is employed to calculate a second salt so that the client can use this new salt in the hash function, but does not know the original salt. <\/span><\/p>\n

    Proving that the client got the right key K<\/i><\/b><\/h3>\n

    The client has derived a key K, but the server doesn\u2019t know what it is or whether it\u2019s the right key. <\/span><\/p>\n

    When the user registers on the server for the first time, she generates a strong public and private key for a secure agreement protocol, and encrypts the resulting private key under K, along with the public key of the server into a ciphertext. Let\u2019s call this ciphertext C.<\/span><\/p>\n

    The server sends the stored ciphertext C to the client. If the client entered the right password into the first phase, she can derive K, and now decrypt this ciphertext. The server verifies the clients\u2019 inputs against its copy of the client\u2019s public key, and the client does similarly.<\/span><\/p>\n

    Whew, that was a lot of information to handle. <\/span>But the point is the PAKE protocol is a perfectly secure protocol being overlooked for not-so-valid reasons.<\/span><\/i><\/p>\n

    – Nishanth Subramanian<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

    You know that guy who does a lot of work but just doesn\u2019t get the attention he deserves? The PAKE Protocol is that guy. PAKE – One of the most efficient cryptographic protocols ever drafted yet rarely gets used. NOTE : Throughout this article, there might be words you have never heard of. I have…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_exactmetrics_skip_tracking":false,"_exactmetrics_sitenote_active":false,"_exactmetrics_sitenote_note":"","_exactmetrics_sitenote_category":0,"footnotes":""},"categories":[25,10],"tags":[79,78,80],"class_list":["post-292","post","type-post","status-publish","format-standard","hentry","category-sanganitra","category-tech","tag-cryptography","tag-pake-protocol","tag-security"],"_links":{"self":[{"href":"https:\/\/nitk.acm.org\/blog\/wp-json\/wp\/v2\/posts\/292","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/nitk.acm.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/nitk.acm.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/nitk.acm.org\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/nitk.acm.org\/blog\/wp-json\/wp\/v2\/comments?post=292"}],"version-history":[{"count":1,"href":"https:\/\/nitk.acm.org\/blog\/wp-json\/wp\/v2\/posts\/292\/revisions"}],"predecessor-version":[{"id":294,"href":"https:\/\/nitk.acm.org\/blog\/wp-json\/wp\/v2\/posts\/292\/revisions\/294"}],"wp:attachment":[{"href":"https:\/\/nitk.acm.org\/blog\/wp-json\/wp\/v2\/media?parent=292"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nitk.acm.org\/blog\/wp-json\/wp\/v2\/categories?post=292"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nitk.acm.org\/blog\/wp-json\/wp\/v2\/tags?post=292"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}