Crypto Corner
www.cop.og/c
73
Timing attacks have continu-ally improved, even being per-ormed against an SSL (SecureSockets Layer) implementationover a network.
2
New ways to l-ter jitter have improved the distin-guishability to 200 ns over a LANand 30
m
s over the Internet.
3
At-tacks have also exploited new sidechannels. Power consumption, RFand electromagnetic emissions,sound, vibration, and even heatgive away inormation about secretcomputations. These attacks aren’tmerely the subject o research pa-pers. Smartcards used or payment,transit, and satellite TV have beencompromised by both active aultinduction attacks (“glitching”) andside channel attacks. Hackers useda timing attack against a secretkey stored in the Xbox360 CPUto orge an authenticator and loadtheir own code.
4
Embedded-systems designersare no longer the only ones whomust prevent side channel attacks.Previously, network-based timingattacks against SSL were the onlyside channel attack most sotwaredevelopers needed to consider.But today, virtualization and ap-plication-hosting services such asAmazon S3 have given attackersa more privileged vantage pointo running code on the same sys-tem (possibly even at the sameprivilege level) as the target’s code.Also, high-speed multicore CPUswith large caches and complicatedinstruction- and data-dependentbehavior provide more possibili-ties or side channels and greater precision or measurements.To illustrate side channel at-tacks against sotware cryptogra-phy, I analyze three recent attacks.Each is increasingly more pow-erul, to the point where the at-tacker can recover an entire RSAkey by measuring the behavior o a single decryption operation.
Keeping the Correct Answer Secret
The HMAC (Hash MessageAuthentication Code) hashconstruction is oten used to au-thenticate messages. To computea given message’s HMAC, thesender hashes the message anda secret key twice using a cryp-tographic hash algorithm (or example, SHA-256). The re-sult is attached to the message.The recipient then calculates themessage’s HMAC via the sameprocess and compares the resultto the value included with themessage. I they match, the mes-sage wasn’t tampered with ater the sender calculated the HMAC.One subtlety with this pro-cess is that the value the recipientcalculates must be kept secret.Consider what would happen i the result were revealed to thesender in the case o a mismatch,perhaps as part o an error mes-sage. An attacker could submit amessage with an invalid HMACeld, observe the error message,and then resend the same mes-sage with the correct value at-tached. The recipient wouldaccept this message as valid, eventhough the sender didn’t createthe authenticator. Although mostsystems probably don’t reveal thecorrect HMAC value directly,a side channel attack can otenproduce the same eect.I recently reviewed the open-source Google Keyczar cryp-tographic library or possibleaws.
5
This library provides use-ul high-level key managementeatures, with separate imple-mentations in Java, Python,and C++. Keyczar includes anHMAC implementation or au-thenticating messages.The Python code comparedthe received and calculated bytevalues as ollows:
return self.Sign(msg) ==sig_bytes
The Java code was equivalent.The underlying compari-son operator or both high-levellanguages perorms a byte-wisematch o the two arrays. I any el-ement didn’t match, the compari-son loop would terminate early.This would provide a timing sidechannel in which the attacker could iteratively ll in guesses or each byte o the HMAC eld, re-submitting the same message eachtime. When the guess was cor-rect, the comparison would take alittle longer. Eventually, when thewhole HMAC was correct, the re-cipient would accept the message.An implementation o this at-tack over a TCP connection tolocalhost took about a thousandqueries per byte o the secret key.This means that an attacker couldnd a 128-bit key in less than aew minutes. Because the arraycomparison operators in Java andPython aren’t implemented na-tively, the timing dierence or each loop iteration was relativelylarge. But even i there was morenetwork jitter or the comparisonloop was aster, the attacker couldsimply take more samples, applyan appropriate lter, and perorma statistical hypothesis test to de-termine which guess was correct.The solution to this problem isto implement a comparison unc-tion that doesn’t terminate early.Although this might sound easyat rst, eliminating all conditionalbranches rom a comparison loopis surprisingly difcult. Even witha correct algorithm, some un-derlying detail o the high-levellanguage implementation (suchas garbage collection) could still
Power consumption, RF and electromagnetic emissions,sound, vibration, and even heat give away informationabout secret computations.