1
00:00:02,420 --> 00:00:08,870
Let's move on that the security measures for ensuring data confidentiality as we've said the first security

2
00:00:08,870 --> 00:00:17,410
measure developed was what or what key is indirectly used not only for secure data but also to authenticate

3
00:00:17,410 --> 00:00:25,780
computers one access point doesn't encrypt frames it can't decrypt if the frames were encrypted with

4
00:00:25,780 --> 00:00:28,770
an incorrect Webcke it will be rejected.

5
00:00:30,040 --> 00:00:34,040
What are the flaws of the web technology.

6
00:00:34,090 --> 00:00:39,020
One of the fundamental rules of cryptography is that one should not be used frequently.

7
00:00:40,210 --> 00:00:43,540
The more often you use the same key the less secure it becomes

8
00:00:47,610 --> 00:00:53,040
the standard doesn't define any solutions for automating key generation.

9
00:00:53,100 --> 00:00:59,810
If you wanted to change a key you'd have to do this manually and separately for each computer as a result

10
00:00:59,810 --> 00:01:00,610
of this.

11
00:01:00,620 --> 00:01:02,000
These are rarely changed

12
00:01:06,400 --> 00:01:09,030
the encryption used in the standard is weak.

13
00:01:09,310 --> 00:01:14,710
The process can be seen in the picture below.

14
00:01:14,870 --> 00:01:19,040
It's necessary to calculate the checks some of the packet first.

15
00:01:19,170 --> 00:01:23,990
It's an ordinary CRC checksum not a cryptographic hash function.

16
00:01:24,000 --> 00:01:30,310
This means that the well protected packets are vulnerable to tamper and attacker can modify the contents

17
00:01:30,310 --> 00:01:33,540
of the frame and forward it by calculating the correct checksum.

18
00:01:35,650 --> 00:01:43,440
Checksum is hazarded Tuason packet we've mentioned already that this is not secured in any way.

19
00:01:43,520 --> 00:01:48,790
RC for a stream cypher is used for encryption.

20
00:01:48,820 --> 00:01:55,220
We'll talk about this cipher at the end of all modules in secure use of the RC for algorithm is based

21
00:01:55,220 --> 00:02:01,730
on the rule that the key shouldn't be used more than once to encrypt the same data.

22
00:02:01,750 --> 00:02:07,870
If this rule is flouted working the ciphertext is trivially easy.

23
00:02:07,950 --> 00:02:12,070
Or C 4 is based on X or operations.

24
00:02:12,120 --> 00:02:15,560
Let's leave aside cryptographic details for a moment.

25
00:02:15,750 --> 00:02:22,940
The same data is exchanged repeatedly over the network this transmission doesn't relate to people visiting

26
00:02:22,940 --> 00:02:24,910
the same web site.

27
00:02:25,080 --> 00:02:27,420
It's about packet headers having a set structure

28
00:02:29,840 --> 00:02:32,810
predicting field values of the headers is very easy.

29
00:02:33,880 --> 00:02:41,330
Given those randomisation was required to improve security in this case randomisation is provided by

30
00:02:41,330 --> 00:02:44,020
the presence of an initialization vector.

31
00:02:44,210 --> 00:02:50,960
Ivy unfortunately it's just 24 bit 24 bit.

32
00:02:50,960 --> 00:02:55,730
ITV is too small this doesn't end the list of problems though.

33
00:02:55,890 --> 00:02:57,400
We'll return to that soon.

34
00:03:00,710 --> 00:03:09,460
When an I.V. is used data stream has to be mapped to the keystream the exclusive or ex-SO are is used

35
00:03:09,460 --> 00:03:10,610
for this purpose.

36
00:03:12,230 --> 00:03:17,630
The end result is the ciphertext or the encrypted version of a packet that was sent to an access point

37
00:03:20,000 --> 00:03:29,180
length depends on what version it can be a 64 bit or even 256 bit long even if the key is really long

38
00:03:29,540 --> 00:03:32,290
you can ensure the security of a network on its own.

39
00:03:35,760 --> 00:03:40,820
This is due to a small number of initialization vectors.

40
00:03:40,900 --> 00:03:46,630
There's only 16 million seven hundred and seventy seven thousand two hundred sixteen available IVI values

41
00:03:46,630 --> 00:03:49,950
in the pool.

42
00:03:49,950 --> 00:03:55,890
The problem is that the risk of repeated values the risk of collision is much higher than it would seem

43
00:03:55,890 --> 00:03:57,090
at first glance.

44
00:03:58,670 --> 00:04:03,980
It's enough to capture more or less 5000 packets for the risk of finding two packets encrypted with

45
00:04:03,980 --> 00:04:06,340
the same IP to be over 50 percent.

46
00:04:08,530 --> 00:04:14,530
And having the same vector equals having the same key because as we said WEP doesn't support dynamic

47
00:04:14,720 --> 00:04:17,570
change.

48
00:04:17,600 --> 00:04:23,510
This means that we've managed to capture data encrypted with the same key.

49
00:04:23,550 --> 00:04:29,540
All it takes now to extract nearly full information on the key is to combine the ciphertext using ex-SO

50
00:04:29,540 --> 00:04:29,970
or

51
00:04:32,410 --> 00:04:37,250
implementation of this week security mechanism is even worse.

52
00:04:37,420 --> 00:04:44,000
The standard doesn't specify the entities responsible for generating Ivey's this has to be done by a

53
00:04:44,000 --> 00:04:54,300
network card how standard doesn't say initially network card manufacturers use the following system.

54
00:04:55,190 --> 00:05:02,010
One was for the Wii for encrypting the first packet two was for encrypting the second packet three for

55
00:05:02,010 --> 00:05:06,620
the third it was highly predictable.

56
00:05:06,660 --> 00:05:15,820
This means that there can be attacks that consist of assuming a specific value of a vector.

57
00:05:15,830 --> 00:05:20,650
You can also encrypt data but not encrypt headers.

58
00:05:20,670 --> 00:05:25,740
In that case an attacker is not only able to capture physical addresses of the clan he's eavesdropping

59
00:05:25,740 --> 00:05:26,540
on.

60
00:05:26,700 --> 00:05:29,590
You can also modify them.

61
00:05:29,710 --> 00:05:41,370
You can control the packets transmitted in this network.

62
00:05:41,400 --> 00:05:47,630
We've talked about the potential problems connected to adding up checksum to packets this issue will

63
00:05:47,630 --> 00:05:51,720
be noticed for example by korek another's.

64
00:05:51,820 --> 00:05:57,190
If we had a checksum to an encrypted packet there's a one to one relationship between the checks some

65
00:05:57,190 --> 00:05:59,020
bits and the ciphertext

66
00:06:01,590 --> 00:06:06,940
by modifying any checksum bit can determine the validity of any part of the packet.

67
00:06:08,400 --> 00:06:10,900
The checksums will or won't match accordingly.

68
00:06:13,540 --> 00:06:18,820
An access point rejects the packets that have an incorrect checksum.

69
00:06:18,830 --> 00:06:24,100
This is a basic mechanism for maintaining reliability of data sent over wireless networks where there's

70
00:06:24,140 --> 00:06:26,790
a lot of interference.

71
00:06:26,870 --> 00:06:33,490
You can modify a ciphertext byte by byte modify the checksum and see if an access point rejects the

72
00:06:33,490 --> 00:06:36,480
packet.

73
00:06:36,480 --> 00:06:40,770
This will help you make sure whether or not you have correctly cracked the valid combination for the

74
00:06:40,770 --> 00:06:42,090
key for each part.

75
00:06:46,900 --> 00:06:55,110
The RC for algorithm is vulnerable to revealing certain relationships between the key NIV.

76
00:06:55,210 --> 00:06:57,800
How can all of these problems be solved.

77
00:06:57,820 --> 00:07:02,390
Don't use WEP to start with look at the alternative solutions.