Some recent findings and ups & downs... if it's too much blah-blah-text: Just skip to the "Todo" part (and best give some advice about the missing cipher).
are always ugly, and I know that the format isn't made for screen-viewing, but IEEE Std 802.11i-2004 is even uglier as it has enabled all nag & gag features: It's using super-small font, and automatically defaults to using a window with only half screen height, and prevents scrolling across page boundaries, and invokes sudden monster-zooming when accidentally hitting the mouse button - I really don't what the features are good for, and why anyone would enable them, except maybe for mimmicking open standards and/or for claiming ownership of something without actually sharing legible information : /
Hmmmm, the only way to view sections of the document seems to be to copy/paste separate pages into a text editor, and then manually fix the formatting & indents.
Well, and the actual content of the document... the stuff that I am interested in is somewhere in the middle of the doc, but it isn't described very well. It's kinda useless, unless when combining it with the reference code in the appendices. And even then, the reference code doesn't match up with the descriptions in the document. And the wonderful reference code kinda looks as if was neever tested in practice (like passing 6 parameters to a function that accepts only 5 parameters).
The descriptions in the other chapters are also somewhat unclear and bugged, in one place they've declared to compute a MIC (=checksum) starting "at including bit0-2" of a big-endian number (hah?) (interesting problem, that could mean anything, but the answer to that problem turned out to be irrelevant - because, what they've really meant was starting "at including the 5 bytes preceedng" that big-endian number).
The two sections worth reading are the glossary and the hex numbers shown in test cases; that two sections are containing more practially/useful info than the rest of the document.
, there are lots of keys used, and it took some days to get a rough idea what they are used for (and if or how they do relate to the actual wifi password).
The first key needed is the 32-byte PSK: This is calculated by passing the Password and SSID through some SHA1-HMAC function. In total it does requires 8192 executions of the SHA1-HMAC function, which can get quite slow, especially when doing it on ARM7 side. If needed, the calculation could be made about twice as fast by pre-computing the HMAC key only once per 4096 calculations. But, the good thing is that Nintendo has fortunately pre-compted the KSK, and stored it in Wifi-FLASH (alongsides with the original password).
The next key needed is the 32-byte PMK, which is just the same as the PSK, so that one is easy. The next key is 48-byte PTK, this is also computed using three or four SHA1-HMAC's across the PSK (aka PMK) and the BSSID and DSi MAC address, and the two "Nonce" values from the Data #1 and #2 packets.
And then, 16-byte KCK, KEK, and TK are simply the first, middle, last 16-byte fragments of the 48-byte PTK. I've meanwhile managed to compute all those keys, and to use the KCK to verify the SHA1-HMAC (aka MIC checksum) in the Data #2 packet.
are that the reference code implies using SHA1-HMAC for WPA and WPA2, but other sections of the document suggest using MD5-HMAC for WPA, which, I guess that's actually so, and it's making things a bit more difficult as the DSi BIOS has a SHA1 function, but no MD5 function, so I'll have to code MD5 myself (a bit uncomfortable, and consuming lots of memory when using unrolled code).
Yet elsewhere, the document suggests the MIC values not being computed via SHA1 nor MD5, but rather by a scary function named Michael (which, I guess that's just nonsense, or maybe it applies only for the lower-level data-traffic, but not for the initial key-handshake needed for DSi). Anyways, it makes me wonder if the IEEE people were some kind of fundamentalists, threatening the archangel to rightfully kill you with his sword, if you were sneaking for free internet from their precious wifi-network.
: One thing that is intensely used on DSi is RSA. And, interestingly, WPA/WPA2 are badly missing any such private/public key mechanism. That's weird, maybe RSA wasn't so popular back in 2004? Or hardware was too slow? Probably not. WPA and WPA2 do use "different" encryption keys per user, but they differ only in relation to the MAC addresses and Nonce values exchanged in the unencrypted handshake. Well, and on the SSID and Password, but that are usually known to all members of the network (ie. friends & family & roommates & neighbors). Of course, the other network members are "not supposed" to use your handshake data, but if they wanted to spy on you, then I can't see anything that would prevent them from doing so.
In that context, WPA and WPA2 don't give so much more privacy than open networks, the main "benefit" is preventing people without passwords from using the internet for free.
On the other hand, wired LAN isn't encrypted either, so that's having similar privacy issues.
: I also had a look at the AR6002 wifi-firmware, checking if it's really not supporting automatic connection: There's a MD5-HMAC function in there, but it's left unused, and doesn't even have it's function vectors installed (and SHA1-HMAC is missing completely). So it looks as if they were originally planning to add auto-connection on firmware-side, and then moved the code to driver-side, which might have some advantages (if one were having a "driver+fimware" combo), but it's not so comfortable on the DSi (with driverless "romimage+firmware" combo).
: I still need one of the actual keys for ADD_CIPHER. The first ADD_CIPHER command is simply using
TK (the last bytes of the PTK). But I haven't yet found out where the bytes for second ADD_CIPHER are from. Maybe it's from the
KEK (but it doesn't match up)? Or from the GMK and GTK stuff mentioned in the docs? Though I've no idea if GMK/GTK exist in the 4-way handshake seen in the WPA2 log at all (they might exist only in 6-way handshake seen in WPA log). Or the missing cipher might come from the "Key Data" field in the handshake packets...
I've no clue what that "Key Data" is supposed to be used for. Comparing the official docs with the values spotted in Data #2 packet:
Code: Select all
1st byte - Should be DDh - that's true for WPA log, but not so for WPA2 log
2nd byte - Should be Length - that's true
3rd-5th byte - Should be OUI value 00-0F-AC - that's wrong (WPA has 00-50-F2 in there, and WPA2 does have 00-0F-AC, but that's in 5th-7th byte)
6th byte - Should be a cipher suite, whatever why one would need that value
7th-last byte - Should be whatver/unspecified (in practice it's just repeating the above whatever OUI stuff)
Okay, that looks all wrong, and almost certainly totally useless. However, Data #3 has some more "Key Data" in there (about 38h bytes), and it's encrypted. I just don't know if it's worth decrypting. If it's the same useless OUI stuff then it could just be ignored. Some of the extra bytes might be a 16-byte AES-CTR-MAC checksum (which could be ignored, too). Well, and maybe the missing cipher key is in the remaining bytes, or maybe not.
I am afraid that I'll need to give it a try, and check how the decrypted data looks like. In theory, ARM7 has AES decryption hardware, but it does (probably) require endian-adjustment, and Nintendo's AES-CTR-MAC implementation seems to be a bit non-standard, so it might be unable to decrypt anything at all - and might require to implement AES decryption by software : /