0

The Open Authentication HOTP algorithm is considered very reliable when using a 160 bits long secret key. Suppose I have this idea to generate such a 160 bits long key without requiring any further secret key distribution effort beyond the one already performed by the issuer of my EMV credit card:

  • I remix-pad my EMV card PIN (known only to myself and the issuer) with other data (the latter being not necessarily secret) in order to obtain a message which when sent to the EMV card in a Application Cryptogram request (I mean, a cryptogram using a stored symmetric key known only to the issuer, and not the private key of a public-private pair) the response will contain such a "PIN and secret key" dependent 160 bit long key.
  • The issuer, knowing the remix-pad algorithm used for generating said message, as well as my PIN and the symmetric key stored in the EMV card, would thus not encounter any problem in reconstructing exactly the same HOTP secret key anytime the need will arise.

Hence, it should afterwards be possible to use said HOTP secret key for general purpose OATH authentication verified by the issuer.

But, by this procedure, have I perhaps introduced some other subtle vulnerability? (assuming to exclude trivial eavesdropping during such key generation, as that could be done in a trusted hardware environment). Sure enough, one shall then take all the precautions to prevent crooks from gaining access to the card and PIN (precautions, in any case, anyway necessary).

In fact, the generation of said "card and PIN" dependent HOTP secret key could follow a procedure very similar to the one already used by EMV-CAP. I came across a very interesting article "EMV in a Nutshell"
https://www.cs.ru.nl/E.Poll/papers/EMVtechreport.pdf
which also describes (Chapter 3) various EMV-CAP vulnerabilities, at least in some of its implementations. Those kind of vulnerabilities would not appear applicable to my case, as such a HOTP secret key generation procedure would be carried out only once, and such a key will then be used in a separate time based OATH HOTP generator, solely for authentication purposes. Just wondering whether such a method would infringe on the EMV-CAP patent(s).

Improve this question
7
  • you basically describe digest authentication. Even with your tweaks, the usual limits and conditions apply.
    – dandavis
    Feb 5, 2019 at 22:37
  • In the meantime I came across an interesting paper relevant to the subject. I have now edited my question to reflect that.
    – Luca
    Feb 7, 2019 at 12:58
  • Things you might want to consider: 1) Card key it's not a static key that is used for cryptogram generation, but a session key for each ATC. It's actually derived from some card unique key that is in fact derived from issuer master key, card number, card sequence number using one of many algorithms. Data used for derivation along with transaction dynamic populated in authorization request and fed to HSMs for processing when cryptogram verification occurs. 2) PIN is not stored by issuer - it's used only verified in one of many methods by HSMs. Ability to verify is different than knowing PIN.
    – Michal Gluchowski
    Feb 8, 2019 at 5:14
  • Thanks Michal, I am just wondering whether I am perhaps misusesing the term issuer. I meant to use it for whoever is responsible for ultimately managing the HSMs, or is that rather a service provider of the issuer?
    – Luca
    Feb 8, 2019 at 9:20
  • @Luca I don't think that detailed naming would make much difference here. Neither issuer nor their service providers keep PINs or any intermediate cryptographic material.
    – Michal Gluchowski
    Feb 8, 2019 at 16:34

0

Reset to default

You must log in to answer this question.

Browse other questions tagged .