Nonces are supposed to be used only once and be crytographically unique.
But what if the Snonce was always a predictable variation of the Anonce. Say a one was added numerically to create the Snonce, or maybe the Anonce was always XORed with the same binary string,
I have heard that some low-powered client devices actually do this.
How much would this truly affect the security of the association?
It seems like this might be enough by itself, that a product would be denied FIPS-140 accrediation if it were discovered - even if it were otherwise using CCMP encryption.
If that was the case ( predicability of the Snonce from the Anonce )......not good at all, at all. In Crypto, any form of predicability gives people the shivers.
The whole idea of encrypting the Snonce with the PTK ( at the supplicant end ) is to keep it from prying eyes, otherwise all bets are off.
The first frame in the handshake is by necessity, unencrypted. This would be similar in a PKI infrastructure of saying "You know that public key you've got ?.....well if you add one to it, you'll get the private key".
One of the things that cryptographers look for is "complete disassociation of connection between random variables/nonces between both ends".
Obviously, the PMK issue comes in etc.
If you had a situation where there was a pre-shared key and you managed to get your hands on that as well as knowing the two nonces/MAC addresses, that could open the door to all sorts of things....
Is the security "level" (in bits) of the encryption reduced by the number of bits in a nonce?
Or is it more difficult than that - the calculation I mean?
I guess what I'm looking for is a "quantifiable" factor. Kind of like saying that WEP security is really 24 bits shorter than 64 or 128 due to the in-the-clear IV.
A nonce is usually described as a number that will NEVER be reused. The descriptions of the differences between a random number and a nonce can get very involved. Many ?definitions? or descriptions of the differences can be ?too general? or not detailed enough. Others become brain numbing. Number theory becomes very involved with this. I read some papers last year on it, and forgot almost everything about it within days. As can be seen from the following, things can get involved:
Roughly, a particular nonce should NEVER appear again. Imagine you go to China and bump into your next door neighbor who is also there on business. Next year, you go to Italy. Is there a chance that this random act could happen again ? Yes there is, but of course the chances are beyond tiny. However, even though the chances are infinitely small, there is still a chance. Now, if you saw your neighbor in China and then killed him, that would be more of the ?nonce type of situation?. In other words, a one off event. You would never, ever see him again in this life.
There are some differences like that between ?randomness? and ?nonce-iness? ( for want of a better expression ).
What we are more concerned with in the Wi-Fi system is the non-repeatability of the actual nonce. This gets very complex, as the software and hardware for generating nonces needs to be studied in depth to see if there really is ?almost zero chance? of the number showing up again. How ?noncey? are present Wi-Fi systems ? Only detailed tests/manufacturer info would tell us that.
If there are any devices out there that do the ?add one to the Anonce to get the Snonce? business, then that?s pretty scary?..
Should have read my first post more carefully.
What I should have said was "The EAPOL Key Frame containing the Snonce is protected by a MIC during the second part of the four-way handshake". The PTK does not encrypt the Snonce. The PTK of course is used to encrypt the GTK during the third part of the handshake, in order to keep the group key hidden.
PTK calculation takes place at both ends independently, and the two keys should match.
One of the things that cryptographers try to do is to prevent anyone seeing a pattern from one thing to another. For example, from one key to another. We want to try and have no correlation between one key and the next . Now, if we have our Pseudo-Random Function used to generate our PTK, where the PTK =
PRF ( PMK + ANonce + SNonce + AA + SPA ), we should have completely different keys each time the 4 way handshake is used. If we just used the PMK and AA and SPA values in the PRF, we would have the same key generated each time.
The PRF is a form of hash function. These are very tough nuts to crack. We need to introduce some form of variable or variables that will help produce unique keys each time.
That's where the nonces come in. Having both nonces that have no relation to each other will make the chances of producing two identical keys very small indeed. If we had a relationship between the two nonces, then that would reduce the chances of producing keys which were not related to each other.
However, this is all relative. The Anonce itself is already a highly "random" variable. So having one highly random variable and another that is related through addition of one etc would still produce a strongly random hash.
With pre-shared keys, if we can get the PSK itself ( social engineering etc ) and capture the four way handshake, we can of course, get the "keys to the castle".
802.1x is very powerful as it uses higher layer authentication techniques to get a "random" MSK.
If ever someone "cracks" the whole public key/private key business as per certificates etc, we might as well pack our bags.
In previous, 802.1x should be 802.1X?.got to watch that shift key.
Some information about nonce generation from the IEEE 802.11-2007 spec:
8.5.7 Nonce generation
The following is an informative description of Nonce generation.
All STAs contain a global key counter, which is 256 bits in size. It should be initialized at system boot-up
time to a fresh cryptographic-quality random number. Refer to H.6 on random number generation. It is
recommended that the counter value is initialized to the following:
PRF-256(Random number, ?Init Counter?, Local MAC Address || Time)
The local MAC address should be AA on the Authenticator and SPA on the Supplicant.
The random number is 256 bits in size. Time should be the current time [from Network Time Protocol
(NTP) or another time in NTP format] whenever possible. This initialization is to ensure that different initial
key counter values occur across system restarts regardless of whether a real-time clock is available. The key
counter must be incremented (all 256 bits) each time a value is used as an IV. The key counter must not be
allowed to wrap to the initialization value.
Section H6 ( toward the end of the spec ) gives some more information
I'm working on my CWSP as the next step in my cert process and working through the study guide. Chapter 3 has some interesting diagrams of the TKIP and CCMP encryption and data inegrity processes as well as the MPDU layouts. I am using an ereader version for convenience sake (works awesomely) but many of the diagrams are turned sideways. I don't know if it's like that in actual printed version but it's very hokey to reference (I'm very visual). Is there any place where one can download these images for printing purposes so they can be read and referenced? -- CazManDo...