Datakommunikasjon høsten 2002

Presentasjon om: "Datakommunikasjon høsten 2002"— Utskrift av presentasjonen:

1 Datakommunikasjon høsten 2002
Forelesning nr 9, mandag 14. oktober Sikkerhet Datakom høsten 2002

2 Øvingsoppgaver Oppgave 1 Oppgave 2
To noder A og B benytter sliding window protokoll med 4 bits sekvensnr. Vindusstørrelse=12 Vis vindussituasjonen for følgende: Før A sender noen rammer. Etter at A har sendt ramme 0, 1, 2, 3, 4 og 5 og B har bekreftet mottak av 0, 1, 2 og 3. Etter at A har sendt ramme 6 og 7, og B har bekreftet 4. Oppgave 2 Du har fått tildelt en IP adresse: med Classless /26. Du skal koble sammen 6 subnett ved hjelp av en ruter. Tegn opp og skriv IP subnettsadresse på de 6 subnettene. Hvor mange maskiner kan du koble på hvert subnett? Hvor mange ledige subnett id-er blir det? Datakom høsten 2002

3 Øvingsoppgaver Oppgave 3 Forklar forskjellen på en svitsj og en ruter.
Forklar hvordan en bro (bridge) fungerer. Hva benytter du hvis du skal sammenkoble to subnett? Forklar hvorfor. Datakom høsten 2002

4 Sikkerhet Autentisering (identifikasjon)
Aksesskontroll (aksess til ressurser) Konfidensialitets (informasjon holdes hemmelig) Integritetstjeneste (data skal være korrekte) Tilgjengelighet (informasjonen skal være tilgjengelig for de som er autorisert) CIA – Confidentiality Integrity Availability Datakom høsten 2002

5 Symmetrisk kryptering
Alice Bob Secret Key Cleartext Ciphertext Cleartext Encryption Algorithm Encryption Algorithm Encipher Decipher BOB og ALICE benytter samme hemmelige nøkkel Datakom høsten 2002

6 Another Key to Encipher
Asymmetrisk kryptering BOB benytter ALICE sin offentlige nøkkel ALICE benytter sin private nøkkel Alice Bob One Key to Encipher Another Key to Encipher Cleartext Ciphertext Cleartext Encryption Algorithm Encryption Algorithm Encipher Decipher BOB og ALICE benytter forskjellige nøkler Datakom høsten 2002

7 HASH funksjon En hash funksjon tar som input en vilkårlig melding med variabel lengde Output er alltid en melding med fast lengde SHA-1 (Secure Hash Function) Output er alltid 160 bits MD5 (Message Digest no 5) Output er alltid Datakom høsten 2002

8 Krav til HASH funksjon Må kunne benyttes på en datablokk av vilkårlig størrelse Må produsere en melding med fast lengde uavhengig av lengden av input Det må ikke være mulig å gjenskape den opprinnelige teksten basert på resultatet av hash funksjonen To forskjellige meldinger må ikke kunne gi samme resultat fra hash funksjonen Datakom høsten 2002

9 Melding sendt til Alice
En veis hash (1) Bob Tekst Hash Algoritme Digest Tekst Melding sendt til Alice Digest Datakom høsten 2002

10 En veis hash (2) Alice Mottatt tekst Digest Hash Algoritme Digest Hvis Digest = Digest Mottatt tekst OK! Sikrer integritet, dvs at teksten ikke er endret under overføring Datakom høsten 2002

11 Autentisering Message Authentication Code
Hvordan vet Alice at meldingen kommer fra Bob ? Bob kombinerer hash funksjonen med symmetrisk eller asymmetrisk kryptering (Hash + kryptering) Resultat = MAC, Message Authentication Code Hash Algorithm + Secret key Datakom høsten 2002

12 Secret key Autentisering (Felles hemmelig nøkkel)
Bob Melding + Secret key Hash Algorithm MAC In the case of a secret key cryptography used for authentication, the message is concatenated with the secret key, and the hash function is applied to this concatenation. The result of this operation is the Message Authentication Digest. Melding Melding som sendes Alice MAC Datakom høsten 2002

13 Secret key Autentisering (Felles hemmelig nøkkel)
Alice Melding + Melding MAC Secret key Hash Algorithm MAC Once Alice receives the authenticated message, she reapplies the hash function to the concatenation (message + secret key). She compares the recalculated MAC to the MAC calculated by Bob. If the results agree, the secret key used by the sender is the same as that used by Alice for recalculating the MAC. The message was therefore truly sent by Bob. = Hvis MAC MAC OK ! Datakom høsten 2002

14 Public key Autentisering (signatur, bruk av privat og offentlig nøkkel)
Bob Encryption Bob’s Private key Tekst Hash Algorithm Digest *  ^1 ’ In the case of public key cryptography, the message digest calculated by Bob is ciphered with his secret key. The MAC obtained, which takes the name of digital signature, is joined to the message. Tekst Melding sent til Alice *  ^1 ’ Datakom høsten 2002

15 Public key Autentisering (signatur, bruk av privat og offentlig nøkkel)
Alice Tekst *  ^1 ’ Hash Algorithm Digest Hvis = Decryption Bob’s Public key OK ! Alice receives the signed message; she recalculates the digest, and deciphers the signature with Bob’s public key. If the two digests agree, the signature received was truly calculated with Bob’s private key. Bob really is the sender of the message. Digest Datakom høsten 2002

16 IPSec – IP Security Sikkerhetsmekanisme for beskyttelse av VPN
VPN – Virtual Private Network VPN over Internett Mellom avdelingskontorer Mellom hjemmekontor og jobb Mellom leverandør og kunde Datakom høsten 2002

17 IPSec sikkerhetstjenester
Konfidensialitet Informasjonen krypteres Integritet En veis hash funksjon Autentisering MAC (hash + hemmelighet) Digital signatur Datakom høsten 2002

18 To sikkerhetsprotokoller
AH (Authentication Header) RFC2402 Data Integritet Autentisering ESP (Encapsulating Security Payload) RFC 2406 Konfidensialitet Datakom høsten 2002

19 To former for IPSec : Transport and Tunnel Mode
Transport Mode IP Header Data Original IP Header IPSec Header Data Tunnel Mode Optional Encryption Outer IP Header Inner IP Header New IP Header IPSec Header Original IP Header Data Optional Encryption Datakom høsten 2002

20 Eksempel : Transport Mode
IPSec Host IPSec Host Internet Untrusted Network IPSec Data IP Header Transport Mode in only applicable to Hosts. It is not available for Security Gateways. When a Security Gateway works in Transport Mode, it acts as a host : the traffic is destined to itself. In transport mode, the IPSec header is inserted after the IP header and before an upper layer protocol (e.g., TCP, UDP, ICMP, etc). Datakom høsten 2002

21 Eksempel : Tunnel Mode IPSec System IPSec System Internet
Untrusted Network IP Header IPSec Data Tunnel Mode is applicable to Hosts and Security Gateways. Security Gateways only support tunneled mode. The outer IP source and destination addresses identify the "endpoints" of the tunnel. The inner IP source and destination addresses identify the original sender and recipient of the datagram. IP tunneling mode allows to use public IP addresses in the new outer IP header, while the existing private IP addresses of the original packet are maintained. The new packet is routed in the Internet according to the outer public address ; the public IP header is then deleted by the IPSec Gateway and the original packet is routed in the intranet according to the private IP header. The original IP datagram is not changed at the end of the tunnel except the TTL field that is decremented, and the Checksum field that is recomputed because of the TTL change. Datakom høsten 2002

22 Beskyttelse avhengig av “Mode” og Protokoll
AH ESP Authentication / Integrity Encrypted Tunnel Mode New IP Header AH Original IP Header New IP Header ESP Original IP Header Authentication / Integrity Authentication / Integrity Encrypted With IPSec tunneled mode : If AH is employed, the outer IP header is protected (authenticated), as well as the entire original IP packet. In case of ESP, the protection is afforded only to the tunneled IP packet, not to the new outer IP header. With Transport Mode : If AH is used, the original IP header and the data payload are protected (authenticated). If ESP is employed, no protection is afforded to the IP original header, but data payload are authenticated and may be encrypted. To sum up, ESP do not protect the outer IP header, AH protects the entire IP datagram (including the outer IP Header, and except mutable fields, such as TTL and Checksum) but do not offer encryption services. Original IP Header Header AH Original IP Header Header ESP Transport Mode Authentication / Integrity Datakom høsten 2002

23 Authentication Header (AH)
IP Header AH Payload 8 bits Next Header Payload Length Reserved Security Parameters Index (identifiserer SA) The Protocol Type of the outer IP header contains the value 51. Next Header : 8 bits field containing the next payload type after the AH Header Payload Length : 8 bits field containing the length of the AH header Reserved : Field reserved for future use Security Parameter Index (SPI) : Arbitrary 32-bit value that, in combination with the destination IP address (outer header) and the security protocol, uniquely identifies the Security Association for this datagram. The SPI value is selected by the destination systemat the SA establishment. The values in the range 1 through 255 are reserved by the Internet Assigned Numbers Authority (IANA) for future use. Sequence Number : 32-bit field containing an increasing counter value. It is mandatory and is always present even if the receiver does not choose to enable the anti-replay service. The Sequence Number is initialized to 0 when the SA is established. Then the first packet will have a Sequence Number of 1. Authentication Data : Variable length field containing the Integrity Check Value (ICV). The algorithm used to compute the ICV is specified by the Security Association. A compliant implementation must support HMAC-MD5 and HMAC-SHA-1 algorithm. The ICV is computed over : the immutable or predictable fields of the outer IP header (Version, IP Header Length, Total Length, Identification, Protocol, Source and Destination Address) ; mutable fields are set to 0 (TOS, Flags, Fragment Offset, TTL, Header Checksum). the AH header (with the field Authentication Data set to 0) the upper level protocol data inserted after the AH header. Sequence Number (Antireplay) Authentication Data (resultat av f.eks HMAC-MD5) 32 bits Datakom høsten 2002

24 Encapsulating Security Payload (ESP)
IP Header ESP Header Payload ESP Trailer ESP Auth Security Parameters Index (SPI) Sequence Number Authentication Payload Data Encryption Padding Pad Length Next Header The Protocol Type of the outer IP header contains the value 50. Security Parameter Index (SPI) : Arbitrary 32-bit value In combination with the destination IP address (outer header) and security protocol (AH), it uniquely identifies the Security Association for this datagram. The SPI value is selected by the destination system at the SA establishment. The values in the range 1 through 255 are reserved by the Internet Assigned Numbers Authority (IANA) for future use. Sequence Number : 32-bit field containing an increasing counter value It is mandatory and is always present even if the receiver does not choose to enable the anti-replay service for a particular SA. The Sequence Number is initialized to 0 when the SA is established. Then the first packet will have a Sequence Number of 1. Payload Data : Data included in the original IP packet If the encryption service is selected, and if the encryption algorithm requires cryptographic synchronization, an Initialization Vector (IV) is included at the beginning of the Payload Data field. Padding : Some encryption algorithm requires the plaintext to be a multiple number of a block size. The padding is then used to fill the plaintext until it reachs an appropriate size. The plaintext consist of the Payload Data, the Pad Length, and the Next Header fields. Pad Length : Size in number of byte of the Padding field Next Header : 8 bits field containing the type of data in the Payload Data field Authentication Data : Optional variable length field containing the Integrity Check Value (ICV). The field is present only if the authentication service is specified by the SA. The algorithm used to compute the ICV is specified by the Security Association. A compliant implementation must support HMAC-MD5 and HMAC-SHA-1 algorithm. The ICV is computed over the ESP packet minus the Authentication Data field : SPI Sequence Number + Padding + Pad Length + Next Header. If the encryption service is selected, the last 4 fields are in cyphertext form, as the encryption is applied before authentication. Authentication Data (variable size) 32 bits 8 bits Datakom høsten 2002

25 SA- Security Association
SA = All informasjon som trengs for å etablere en sikker forbindelse Valg av sikkerhetsmekanismer: ESP or AH beskyttelse Krypteringsalgoritme Hash funksjon Valg av autentiseringsmetode Autentisering av partene Valg av krypterings- og autentiseringsnøkler Datakom høsten 2002

26 Security Databases To Security Databases ifm IPSec
Security Association Database (SAD) Benyttes på en allerede oppsatt forbindelse Security Policy Database (SPD) Definerer den policy som skal benyttes mellom f.eks to subnett. Datakom høsten 2002

27 SAD - Security Association Database
For hver SA (Security Association): Identifier : Outer destination IP-address Security Protocol (AH eller ESP) SPI (Security Parameter Index) Parameters Authentication algorithm and keys Encryption algorithm and keys Lifetime (hvor lenge kryptonøklene er gyldige) Security Protocol Mode (tunnel or transport) Anti-replay service (sekvensnummer) Datakom høsten 2002

28 SPD - Security Policy Database
Hver regel inneholder: Selectors: Destination IP Address Source IP Address Name Transport Layer Protocol (protocol number) Source and Destination Ports The policy : Discard the packet, bypass or process IPSec For IPSec Processing : Security Protocol and Mode Enabled Services (anti-replay, authentication, encryption) Algorithms (for authentication and/or encryption) Datakom høsten 2002

29 Security Association Etablering
Security Associations forhandles: Manuelt IPSec kun mellom et lite antall maskiner Automatisk Skalerer bra Automatisk forhandling om SA er spesifisert i: ISAKMP RFC 2408 IKE (Internet Key Exchange) RFC 2409 Datakom høsten 2002

30 Automatisk SA forhandling
IKE definerer to faser: Fase 1 : Etablering av en sikker forbindelse mellom partene Kalles ISAKMP Security Association ISAKMP SA negotiation Nøkkelutveksling Autentisering Fase 2 : IPSec SA forhandling i ISAKMP kanalen som ble etablert i fase 1 Datakom høsten 2002

31 Internet Key Exchange Fase 1: Fase 2 Main mode
To meldinger for algoritmer og autentiseringsmetoder To meldinger for utveksling av offentlige Diffie-Hellman nøkler To meldinger for autentisering Aggressive mode (raskere enn Main mode) Ingen beskyttelse av autentiseringen Fase 2 Quick mode Oprettelse av IPSec SA Datakom høsten 2002

32 Diffie-Hellman: Nøkkelutvekslingsprotokoll
Protokoll som benyttes til å utveksle en DH hemmelig nøkkel mellom partene Denne nøkkelen benyttes så til symmetrisk kryptering Symmetrisk kryptering er 100 ganger raskere i SW og 1000 ganger raskere i HW enn asymmetrisk kryptering Datakom høsten 2002

33 Diffie-Hellman DH private key Bob’s DH public key Alice’s DH
DH Secret key Datakom høsten 2002

34 Cisco - IPSec inbound ESP SA: spi: 0x62910BD( ) transform: esp-des esp-sha-hmac , in use settings ={Tunnel, } slot: 0, conn id: 2000, flow_id: 1, crypto map: telenor-map sa timing: remaining key lifetime (k/sec): ( /2780) IV size: 8 bytes replay detection support: Y outbound ESP SA: spi: 0x217B2368( ) transform: esp-des esp-sha-hmac , in use settings ={Tunnel, } slot: 0, conn id: 2001, flow_id: 2, crypto map: telenor-map sa timing: remaining key lifetime (k/sec): ( /2780) IV size: 8 bytes replay detection support: Y Datakom høsten 2002

35 IPSec og brannmurer IPSec AH - IP protocol ID 51
IPSec ESP - IP protocol ID 50 IKE - UDP port 500 Datakom høsten 2002