i'm actually learning how WEP and TKIP works and what are the main differences and weakness.
Unfortunately, it's not so clear to me how the ICV and MIC is calculated.
From 802.11-2007 RFC, i read:
ICV: "The WEP ICV, ..., is calculated over the plaintext MPDU Data (PDU) Field."
MIC: "MIC is calculated over MSDU SA, MSDU DA, MSDU Priority, MSDU plaintext data"
Looking at them this way, they are actually the same for me as it seems that they're calculated over the same portion of the frame.
It says that ICV is calculated over the payload of the MPDU; an MDPU should be made of:
"Mac Header + payload", where in the payload we should have "IP Header + payload", namely an MSDU.
So if the ICV is calculated on the MPDU's payload, the ICV is calculated on the entire MSDU (so the ICV "protect" also the IP Header).
The MIC, instead, is calculated on the SA, DA, Priority, payload of the MSDU.
The only differences i see there, is that the MIC is calculated on the payload and just on a part of the IP header of an MSDU, while the ICV protect the entire MSDU.
I'm pretty sure that my conclusion is wrong cause when my book compare ICV and MIC says that "while the MIC is calculated over the entire MSDU, the ICV is calculated only on the payload of the MSDU"; but if i look at what is written in the RFC, i find something wrong.
Can anyone clarify this?
Your help is appreciated, Thanks.
Very good questions. I'm writing up some info for you. There are some historical issues that need to be looked at, to put everything in context.
When you mentioned "the book", are you refering to the CWSP study guide ? If so, what page. If not, which book is it ?
Let?s first go back a bit in time to the beginning of Ethernet. Ethernet revolutionized the manner in which networking operated. When Bob Metcalfe drew the first sketch of Ethernet on the back of a napkin, few could have realized at the time that this would begin a process of having a standardized system of data link interconnections that would become the premier method, worldwide.
The ancients believed that the Sun?s rays were able to be conducted to the earth by means of an unseen medium known as the Ether. The name was taken from this.
In those days, the word ?hacker? was unheard of. Governments and large corporations often used proprietary systems to communicate. It was assumed ( and in fact some of the older RFCs make reference to this ) that the ?wired network is assumed secure?.
This is an inherent assumption in the circuit switched landline telephone system. Although a hacker could indeed physically tap ( literally ) into a telephone line ( as in the movies ), or at the telephone switching office, this was assumed ?too difficult to perform for practical purposes?. Any call made on a conventional landline is in ?clear? unless cryptographic equipment is utilized at each end. In the movies you?ll hear ?Scrambler activated Mr. President??.
Society was different. The Internet was being developed by Governmental and some private groups. The days of someone switching on an I-Phone and saying ?Man, is Miley Cyrus really wearing that ?? were a long way away.
Security was not a major concern for the private sector at the time.
Ethernet operates in a wired environment. In other words, the electromagnetic pulses that travel along the ( at that time ) metallic media were regarded as being ?securely contained?. Of course, we now know that these signals can ?leak?. At that time, the media being used was coaxial cable. Provided that the media was properly shielded and grounded, it was regarded as being secure. Again, this is referring to the original system.
If private companies felt that they would like more security, cryptographic equipment would be used at each end. However, the original Ethernet specification was not really concerned about security. Security would be ?an extra layer? that was at the discretion of the user.
In the next part ( I have to clean the dishes just now?.sad really ), we?ll have a look at the propagation characteristics of Ethernet, and what the terms CRC and FCS mean.
Ethernet systems work using digital signals, which we are all familiar with. Most of us would say ?Hey, just ones and zeroes, no problem?. That is true, but on a metallic medium, for example, things become a bit more complicated. Capacitors are devices that can store electrical charge. We see them in use every day in our homes. When we switch off our computers, the little power light on the UPS ( and sometimes the computer ) oftentimes does not ?snap off? at once, but gradually decays. Capacitors in the power supply ( often used for filtering purposes ) have held on to some charge, and when we remove the mains power source, the capacitor slowly discharges in an exponential manner. We also use them for the flash in cameras ( you can sometimes hear an audible whine as the capacitor charges ).
What appears to be a simple old piece of cable or wire can actually ?become?quite a complex entity, electrically speaking, as the frequency of the signal increases. At DC ( Direct Current ), and low frequencies, the cable just appears to have a little resistance. As the frequency increases, the cable ?appears? highly complex to the electrical signal. The cable has capacitance. It has inductance ( related to effects to do with magnetic fields ), plus some other ?parts?. The end result is that the cable charges and discharges as an electromagnetic signal propagates down it.
A signal that started off at one end as a nice clean square or rectangular pulse at one end becomes distorted in shape. It?s height or amplitude reduces as well.
A French Scientist, Jean Baptiste Fourier found an amazing thing. If we have a periodic signal ( in other words, repeating itself regularly ), we can break it down into a pile of sine waves of different frequencies and heights ( sine/cosine/phase comes into play, but we won?t get into that here ). Higher frequency waves are affected more by the cable than lower frequency waves. What happens is that as the higher frequency waves are reduced in amplitude, the whole shape of the digital pulse changes. At the receiver, logic circuitry will say ?Is this signal above a threshold value or below a threshold value ?? It will then say ?We have a one or a zero?. The problem is that if the length of the cable is too long, what started out as a ?one? may be corrupted to become a ?zero?, even with absolutely no interference at all. We?ll talk about what happens with interfence later.
OFDM would be very difficult to achieve without that chap.
Ethernet maximum cable lengths are due mainly to timing issues on collision detection. We won?t get into that here, but suffice to say that cable length and cable quality are very important in deciding how far pulses can reach without affecting accuracy of reception.
The designers of Ethernet faced a couple more hurdles. Firstly, if we have a large number of one pulses, one after the other ( a series of boxes all touching each other ), due to the electrical characteristics of the cable, a DC voltage could build up along the line. Without going into details, this could cause problems with the signal. The second problem was synchronization. Just like with 802.11 physical layer headers, we have a preamble. Preambles do a bunch of things in both Ethernet and 802.11. They identify the beginning of the ?meat of the frame? via a known pattern that the receiver can recognize, but they also provide timing information to ?lock? the receive clock. If we have a whole bunch of ones in Ethernet, we may lose sync when we have a long frame.
In order to get around the problems of DC bias ( the DC buildup ), as well as timing issues, a clever system known as Manchester Encoding is used. This uses special pulses that vary positive and negative and can convey timing information ( timing is always taken from a signal transition state zero to one or one to zero?.this is simply because the timing circuitry will contain digital devices such as D type edge triggered latches and shift registers ).
So, now we have pulses which are allowed to be sent only a certain distance by the specs ( e.g. 100 m ?.note for cable that complies with CAT specs?.anything else, all bets are off ). We also have taken care of timing and DC biasing issues. What are we left with ? Addressing and what to do about damaged frames come next ( we won?t go into the whole media access business ). We?ll talk about the latter two in the next post and then get into the meat of this ( have to get the dinner started?.even sadder ).
Most of us are familiar with the manner by which Ethernet frames are addressed. We have unicast frames meant to be processed by only one particular receiver. We have broadcast frames that are meant to be processed by all receivers, and we have multicast frames which are meant to be processed only by that group of receivers who have requested to be members of a particular multicast group by means of ( say ) an IGMP join request .
?Processed? is the operative word here. Processing takes up precious CPU cycles, and in a system such as Ethernet ( CSMA/CD ) and 802.11 ( CSMA/CA ), time is precious. If you can recognize that the frame is not for you, early on at the lower layers of the OSI or TCP/IP model stack, you can discard them at that level rather than letting them go all the way up the stack to the application layer ( say ), and then saying ?Oh, I don?t need to see that?.
Ethernet frames use 48 bit MAC ( Media Access Control ) addresses. They are split into two 24 bit groups. 12 hex characters. 6 hex characters in each group. The IEEE envisaged that no two MAC addresses on publically reachable networks or internal networks for that matter would be the same. An OUI ( or Organizationally Unique Identifier ) was assigned to each manufacturer. That took care of the first 24 bits. The manufacturer could then assign the remaining 24 bits to their cards. Each card?s ?MAC serial number? should be unique. We can have all the fancy IP addressing we want, but it always boils down to data link/physical addressing at the bottom of the stack.
A series of reserved IP addresses are assigned for multicast working. However, we somehow have to translate those values at some time, into actual physical hardware addresses. Anybody who has gone through the ?Cisco math? for that knows that it can be a pain, doing it manually, but gives you a good feel for the process.
There are a few other bits and pieces that we sometimes see in Wi-Fi protocol analysis traces ( depends upon the device ). We will sometimes see ?Group bit? and ?Local bit? alongside the 48 bit MAC address.
Let?s look at Group Bit first. If we look at the diagram in the link above, we can look at the very first byte of the group of six bytes in the MAC address. We won?t get into bit ordering/transmission here, as that can get confusing, but if we look at the very first bit of the very first byte, we can see that bit discriminates between whether the frame has a unicast ( zero ) or multicast ( one ) meaning. We have two addresses in Ethernet, destination ( first, for speed of processing?e.g. Cisco Cut Through etc ) and source. In the source address, bit one is always zero, irrespective of unicast or multicast.
We often see reserved MAC multicast ranges from Cisco for example, from 01.00.5e.00.00.00 through 01.00.5e.7f.ff.ff
We can see the ?1? in the first block of two hex digits ?01?: 00000001
The next one is sometimes marked ( on Wi-Fi analyzers etc ) as the ?Local bit?. The idea with the OUI system is that each card should theoretically be unique in the whole world !! Just like with routable IP addresses. Provided the manufacturers ?play by the rules?, that should be the case.
If the second bit of the first byte of the destination MAC address is a zero, it means that the card manufacturer has been assigned an OUI and is using a unique sequence for the remaining 24 bits of the address.
If the second bit is a one, that means that the system does not use the standard OUI system ( we say it is over-ridden ):
So now we have addressing and timing/DC bias/cable length taken care of ( optical fibre still has some of the same issues?degradation/timing etc?fibers have impurities etc ).
Now we need to look at signal collisions and interference.
?Cheers? has just come on the telly, so that will have to be next. Have seen all the epsiodes umpteen times, but it is a true classic.
What about 900MHz stuff??? Or is that in a latter issue of Dave?s life and times of the internet/networking/WLAN?
Old Bob was such a sourpuss about 3Com; it?s sad to see them evaporate.
Wow, thanks for the history lesson Dave!
Actually I wouldn?t be surprised at all if lower frequency bands opened up again in the future. White Space trials have been doing pretty good in some locations. When .11ac shows up, even the 5GHz band is going to get very crowded. It?s fine and dandy talking about massive bandwidth, but problems come along with that as well. In the next decade, as we see cellular offload to hotspots etc, both bands are going to get pretty congested in some places.
Looking at the .11ac docs and seeing ?megabonding? makes me wonder about DFS. If I?m a little guy and a DFS event comes along, I have to ?hop? elsewhere. Usually no probs for a little 20 MHz guy. If I?m a big .11ac carrier, I might not have any physical spectrum to ?hop? to ( with the same large bandwidth ) after I?m told ?Close down for x seconds and move?. Do I reduce my bandwidth to ?squeeze into a smaller area? or what ? lots of issues here, depending upon environment etc. Possible layers of protection ?against? .11n etc. Could get tricky under some circumstances. Anyways, that?s for other times.
As the electrical pulses are sent down the line, there are two main problems. One, collisions with other frames, due to the nature of CSMA/CD, and two, interference.
This caused a few headaches for system designers. How to decide when a frame is corrupted, and what to do about it. Some may be asking what all this has to do with the original question. I could give a three line reply easily. However, by having a glimpse into how Ethernet works, we find many things out about how Wi-Fi works. There are very,very few areas of Wi-Fi that do not have their roots in previous work. At the time when Ethernet was coming out, microprocessors were appearing on the commercial market. They lacked the speed and processing power of modern units. Designers had to decide ?Do we take information about a corrupted frame and try to deal with it at layer 2 in some form of HDLC like system or do we simply discard it and let timers at say, the TCP transport level take care of it ? This was one of the questions that 802.11 designers had to face. Speed of communication and restrictions on processing power ( as we will see with TKIP ) were important concerns.
The designers decided to have layer 2 simply discard a frame that had been involved in a collision/had been subject to interference. They could have used ACK ( acknowledgement frames ), but decided not to, as the actual interference environment ( closed co-ax at the time ) was pretty much interference free ( provided there was proper shielding and grounding ). Wi-Fi was different, as the media environment had all sorts of potential problems ( other unlicenced carriers, refraction, diffraction and who knows what else ). Postive acknowledgement was the way to go with 802.11, simply due to the unbounded media in use.
Now they had to find a method of detecting frame errors. We?ll just talk about a bunch of PCs on an ethernet network and won?t look at switches ( cut-through, fragment-free etc ).
Because of processing limitations, whatever was going to be used had to be fairly simple and quick. An algorithm ( a step by step mathematical procedure to complete a task in a usually fairly fixed number of steps ) was used. The type used was known as a Cyclic Redundancy Check or CRC. We?ll look at the mechanics of that next, then in another post why it?s cousin in WEP gave so many problems. Then we?ll see that WEP is still alive and kicking despite what is often said. It?s heart and soul are actually still there in WPA etc , albeit buried in TKIP.
What did he just say ????
Strange but true. It?s only when we get to CCMP-AES that poor old WEP is truly gone forever.
Now we can take a look at how the CRC ( Cyclic Redundancy Check ) works. We first take a block of data. We are now going to pad the end of the data block with a number of zero bits, which we shall call ?n?. So we have a bunch of data, and some zero bits tagged onto the end. The value of ?n? is not just any old number, it?s a special value that we shall see soon. We now divide that whole package ( data plus zeros ) by a special number which has n+1 bits. That number is known to both ends of the link. So, the number of zeros is one less than the special number we are going to use to divide into the data + zeros package.
The number that you divide into something is called the divisor
The number that is being divided by the divisor is called the dividend
The number of times that the divisor ?goes into? the dividend is called the quotient
Whatever is left over is called the remainder
Now, we take our data + zeros and divide it by our special number which is n + 1 bits long. We get a quotient and a remainder. The remainder may be zero, or may not be. That remainder is called the CRC value. We now remove the zero values and add the CRC value on to the end of the data. In Ethernet, that value is placed in the FCS ( Frame Check Sequence Field ). Ethernet in particular actually calculates a CRC not only on the data, but also on some contents of the Ethernet header. The basic process is the same however. Now, we send the whole package to the other end.
At the other end, the reverse process takes place. The card now takes the same divisor used by the other end and divides into the data + CRC value. If the remainder is zero, there is a fairly strong chance that the frame was not corrupted. We will discuss more about how this is not 100 % accurate, and how tampering can take place in Wi-Fi systems.
In case anyone is interested in the math:
In the following video, the Generator is the divisor ( known to both ends ). A polynomial is a bunch of numbers made of ( from left to right ) X to the power zero, X to the power 1, X to the power 2, X to the power 3 etc . We write the values on paper from right to left however. ??.X to the power 3, X to the power 2, X to the power 1, X to the power zero . We need to convert the polynomial value to a sequence of bits that can be used as a divisor.
For example, in the video ( at about 1:30 ) we have : X to the power 5 + X to the power 3 + X to the power 2 plus X to the power zero. We write down ones and zeros from left to right. One when a particular ?X to the power y? is present, and zero when it is not.
Starting from the right, we have X to the power zero true. Put a one there????.1
We do not have X to the power one. Put a zero there????????????????01
We do have X to the power two. Put a one there??????????????????101
We do have X to the power three. Put a one there????????????????.1101
We do not have X to the power four. Put a zero there??????????????01101
We do have X to the power five. Put a one there????????????????.101101
Phew ??had all the columns nicely lined up in Word, but....
I put this info here, as you will often see mention of these polynomials in the IEEE docs. They?re all over the place.
There?s a small ?typo? as pointed out in the comments in the video below:
Next, we?ll look at what WEP does with a CRC and then we?ll get into TKIP, and finally look at the questions.
Just came across this one: History of Ethernet with one of it?s inventors, Bob Metcalfe:
The story is getting interesting :)
I'm looking forward to the next part, WEP, TKIP and finally to the answer :)
Thanks again for your time.
Bye the way,which book/page were you referring to ?
To anyone who is thinking ?When is he going to get to the point ??, a couple of things:
1. I don?t get paid for any of this. Not one penny.
2. There are a million other things I could be doing. I have a bunch of troubleshooting problems going on just now in five separate countries, via Skype.
3. The answers will be at the end. If anyone is not interested in any of this/ too busy, all they have to do is wait sufficient time until all the rest of this is finished, then look at the last post, and be done with it.
4. It would take me about two to three minutes to put down a few lines in response to these particular questions, parrot style. Many people are new to all this. They maybe don?t understand in depth ( and that?s what it?s all about for anyone wishing to really do well in Wi-Fi ). I get so many e-mails each day from people all over the world ( mostly former customers ) asking questions, that I?ve built up a sort of mental check list of what areas need to be answered in depth. Some can be answered in a line or two, but others, not so much. Because they are new, some people don?t want to ?feel embarrassed? on a forum by asking ?well, what do you mean by that ??.
Nobody should ever feel embarrassed by asking questions. I do it all the time. A few months ago, I went to a crime prevention night near my home. We were all fed hot dogs and told what a wonderful job was being done in reducing crime. The Chief of Police was there, along with all the TV crews. I asked him some questions about some really bad things that had been going on in my neighborhood, and to the fact that he had not replied to several dozen letters I had written. A flustered aide said ?You can?t ask that !! This isn?t the place for that ?, as the cameras swung around . I said to him ?You?re right !! Why on earth would a member of the public want to ask questions about crime at a Crime Night Out ?. He told me ?We need to talk about what has been achieved, not what hasn?t?. Ah yes, public relations. And all the kids got crimestoppers badges and ice cream????.
When the doctors couldn?t tell me what was wrong with me, I had to go through a mountain of medical literature from basic anatomy to Latin to spinal surgery. There was no way I could do that in the time frame that I had left before I was due to get my right leg amputated. I bought a book on speed reading. Instead of reading in detail, I would scan using my finger to run along each line as a child would. I then would stop at a particular area of interest and make a note, then onto the next page. I would get through a whole book in a few days. I?d then go back and read in detail, and mentally filter out all the ?extraneous info?. When I read a white paper now, I don?t read everything at once. I spend say two or three minutes standing a few feet away from the computer monitor and let my eyes quickly scan from top to bottom. I mentally make a note of key phrases and paragraphs and then go back and read them in depth later. If it?s a good paper, I?ll slowly read the whole thing. I was forced to develop these techniques due to my health situation at the time. This technique can be used with my babblings here. Scan, boring, scan, boring....ah that's what I want to know.....boring...boring. You can also cut and paste my ramblings into word, and then use the fluorescent highlight marker to mark up something that you are interested in. Just a suggestion.
Unfortunately, on some forums newbies get ?shot down? by some trolls who say things like ?Look it up in the FAQs??don?t you know that ?........refer to Jim?s post from eight years ago?, and all that other abrupt, smug rubbish. Nothing wrong with referring to FAQs etc, but it is the manner in which some respond. Very snippy. We all have to start somewhere. It?s nice to be nice. Who knows, the troll who shoots down some newbie may find the newbie is his boss some day. Even though Forums are ?anonymous?, all sorts of little clues can be picked up as to who a person is, and where they work.
There is an area in one of your questions that has perhaps been missed out/perhaps misunderstood. As we?re talking about Ethernet ( and we?ll see why later on ), we need to chat about something else before moving onto WEP, so we don?t have to come back this area later on.
Before ?leaving? Ethernet, there is an area that is frequently misunderstood in the Wi-Fi arena, and which will tie into the answers of the original questions. That is, the whole issue of LLC/SNAP. These notes will also, hopefully answer some questions that those who are performing protocol analysis may have wondered in the past.
The IEEE 802.11 specs work at two layers: the MAC layer and the PHY layer. The MAC layer itself is part of the data link layer. The data link layer is part of the OSI model, and has two components:
The Logical Link Control Layer
The Media Access Control Layer
Although not an integral part of the formal 802.11 specs, the LLC is intertwined with the inherent working of 802.11.
In order to understand 802.11, we need to go back a bit to understand HDLC, or High Level Data Link Control. In order to do that, we need to know a little about character oriented and bit oriented protocols.
In the early days of digital communications, teletype machines ( telex machines ) were common. Each character was prefixed with a start bit, then we had the character ( 5, 7 or bits usually ), then we had a stop bit, and maybe a parity bit thrown in. This legacy continues today for anyone who has ever used a command line interface with a router ( and some APs, controllers etc ).
Although we may laugh at the machine above, the vast majority of the physical formatting used in Wi-Fi was derived in one way or another from that beast and other technologies like it, when we consider a Telex network. Headers, trailers, addressing, error recovery etc. I was dumped with the responsibility of looking after the Telex machines at a comms facility where I worked, on top of the wireless/satellite/data and phone system. It was a dirty job ( lots of mechanical bits and pieces and grease and oil and ink ), but by stripping the units apart and having to do component level repair on circuit boards, using an oscilloscope and meter, it really gave you a ?feel? for the whole flow of information.
This is a rugged, but highly inefficient system when you are trying to pass large volumes of data. It?s fine ( and simple ) for those who are simply pumping in a few keystrokes at a console. It?s just you and the machine. You?re not sharing the ?line? with anyone.
A little history ( perhaps interesting to anyone who works with serial lines on Cisco gear etc ) and then onto the workings of HDLC.
IBM in it?s heyday was looking for a more efficient way of getting their terminals to talk to their mainframes. The old character oriented system was in use. Having overhead on each character was very inefficient. Comparable in a way to a situation where you precede every Wi-Fi transmission with an RTS/CTS ( by the way, for any newbies, despite what you may read in some otherwise good college technical books, that is the exception rather than the rule??the vast majority of Wi-Fi transmissions do NOT precede their actual data with RTS/CTS?unfortunately, that is what it says in the most used communications textbook, here in the US?authors never got back to me?oh well ).
Someone had a bright idea, by saying?Hey, instead of all this business of prefixing each character with a start bit, then ending it with parity/stop bits etc, why don?t we collect a whole bunch of data, and prefix it with a special header, then put a trailer on it ? ?that way, the ratio of actual data to overhead will be dramatically improved?.
The system IBM created was known as SDLC ( Synchronous Data Link Control ). IBM basically ruled the world as far as computing was concerned. However, nearly all the protocols they used were proprietary or closed standards. The ISO Model was being developed to help create open standards. IBM realised that they would have to invest in open standards as times were changing. ISO and IBM chatted and HDLC was created as an open standard. The ITU-T got involved and a bunch of other standards were created; LAPB, LAPM etc. Frame Relay was derived from the standards. In the next post, we?ll discuss the workings of HDLC.