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"
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).