Hello! I’m trying to perform a side channel attack against the AES portion of MILENAGE authentication in a SIM card. I’ve modified a card reader to capture (what I think are) reasonably good power traces (low-pass filtered, unfortunately the raw power trace looks like a kid’s crayon drawing), and I’ve written some fun and games to align the traces:
Unfortunately, what should be simple CPA refuses to work. Based on the “doubled” key scheduling operation, as well as an unusual number of rounds (14, when AES-128 should be 10?), I think this is an intentional countermeasure, as opposed to poor captures or noise. Other SIM cards I’ve tested look wildly different.
Is there a way to identify whether this is a countermeasure, what general approach I can take against it (if any), or some kind of gallery showing what different countermeasures look like and I’ve just missed it?
If anyone else has done some work in this area: have you seen similar results?
Hi, nice traces! I don’t have any experience with MILENAGE, but others have and have written papers about it, e.g. this one.
Have you tried different leakage models? The updated Jupyter tutorials talk a bit more about this, for example here.
When you say “double” key scheduling and 14 rounds I would immediatelly think AES-256 instead of AES-128.
Hey thankyou both!
Since I made the original post, I’ve done a little on-and-off investigation on this subject - sharing here incase anyone finds it useful (and because I couldn’t find it anywhere else): while previous work on side channelling MILENAGE focusses on attacking AES (as reference implementations of MILENAGE use AES), it’s not required that AES is used, making this exercise much more difficult (but the AES-256 suggestion suddenly becomes way more applicable!)
All but two SIM’s I’ve been able to acquire locally seem to use a shared implementation (“blocks” of power consumption very similar), but initial visual inspection indicates some form of protection is in place (I don’t think it’s low-frequency noise, same samplerate/lowpass cutoff shows clear peaks and blocks in other implementations?) -
Two rays of hope shine through, however:
- Firstly, I’ve found one carrier implementing what looks like DES, supported by the “blocks” of power consumption corresponding to DES operations, right down to the mixing operations count. Initial experiments haven’t shown strong key correlation, analysis continues:
- Secondly, the actual authentication used by MILENAGE seems to fairly flexible, allowing mobile virtual network operators the choice of selecting their own cryptography (i.e. it’s not tied to a physical carrier, so the choice of cryptographic primitive is not determined by the national carriers of your country).
Hope the next person looking at this… back down the rabbit hole