As some of you may be aware, Ron Lapedis and I are providing the Biometrics and Access Token Technology, 10 Years Later session at the 2012 RSA Conference. Our original thought in proposing the session was that given the various hacks, attacks, and leaks of last year there was too much snake oil oozing out of the security industry. IMHO some of the technologies would stand a better chance at solving the budget deficit than providing single sign on or security solutions, but I digress. The value in a retrospect session is that it allows attendees to see where we have been and if things have really changed. Then last week, I saw the Sykipot / defense sector announcement.
The original article I read said "Recently security researchers uncovered a new varient of Sykipot that targeted Smartcards and the defense sector". Of course I was curious so I looked on the web; before any of my friends ask - no I did not click or cut and paste the link that was attached in the email, I did a google search. According to eWeek:
The attack begins with a spear-phishing email message with a corrupted PDF document attached. When opened, the file exploits a recently patched Adobe vulnerability to install the Sykipot Trojan code onto the victim's computer. When installed, the malware uses a keylogger to steal the card's PIN, according to Blasco. Along with smart card log-in credentials, the malware variant can also list the public key infrastructure certificates on the computer's local certificate store. ...
The variant is capable of using the PIN and digital certificates to "silently use the card to authenticate to secure resources, so long as the card remains physically present in the card reader," Blasco wrote.
What does this mean? It looks like someone targeted the US Common Access Card (CAC) with a modified keylogger. The keylogger would not only capture the pin, used to unlock the card, but do its own messages and other transactions.
Once again, social engineering has surpassed the conventional issues of a poorly implemented protocol or component. For example, in the past, in order for me to accomplish the same result I would need to depend on the implementation of a weak Random Number Generator (RNG) facility of the card and on the availability of two transactions to the card.
The RNG was especially important because the Session Key was derived from the card random number. Hence the more often the random number repeated, the more often the session key would duplicate and the better the chances of success the attack had. (As a historical note, 10 years ago the cards repeated their random numbers from 3% to 5% across a 1,000,000 event test sample. The preferred transactions were the select secure file/purse and the following transaction to the file/purse. Given this information one could create their own transactions. The attack looks something like this:
The User sends a random number to the card, and the commands to initiate a secure conversation. The card responds with the random number that was sent to it, a random number that was generated on the card, and the low 4 bytes of a session key. The response is HMAC'ed. The User would then encrypt their random number with the card random number. This in turn would be encrypted with the shared secret. The low four bytes, that were sent with the card response, would be compared against this session key. All subsequent commands would have a 3 byte HMAC (as calculated with the session key).
So the transaction would look like this:
80 28 00 01 08 MyRandom - <initiate transaction and send random #>
<return value plus length of data returned>
<read data length>
CardRand VC## - <Recieve card random number + 4byte Verification Code .>
Then you capture the next command. After which you can replay the transaction whenever you want by sending MyRandom and waiting until it returns a duplicate CardRand. This, while fun is not as good as being able to write your own commands. So you can try and guess the System Key.
In reality, VC## is the low 4 bytes of the session key. This is used for validation that you have the correct session key. You can calculate the session key by doing the following:
TempKey = DES[MyRandom,SystemKey]
SessKey = DES[CardRnd, TempKey)
In order to guess the SystemKey, we still have 264 number of combinations to go through and even with the 4 bytes of the SessKey to validate against, it would take a 'long time'. This having been said, what if we attacked the SessKey? The transaction command (next command after session key) provides a 3 byte HMAC... The HMAC is an keyed (encrypted) checksum, which is derived from the Session Key. Since we have the low 4 bytes of the session key (VC##), and a checksum to compare against the attack becomes reduces from 264 to 232. Thus all one would have to do is cycle through 232 bits and append VC## to get a candidate session key. The session key can then be validated by calculating the HMAC. If the HMACs match that is a possible session key.
By now someone may mention that most cards lock out after a maximum number of attempts for a secure session. This is not a problem, because the session key transaction is not a validation request and so the lockout never comes into effect.
At the end of the day, while doing this still requires access to a couple of transactions, it would give you the ability to generate your own commands, but would require you to wait until the random #s duplicate. Then again, who would have thought that it would be so easy to get someone to install a key logger ?
Posted
Jan 25 2012, 03:15 PM
by
Michael F. Angelo