security services in information systems
DESCRIPTION
Security Services in Information Systems. Basic Concepts. Machine A. Machine B. Key exchange: Diffie-Hellman protocol. 1.Picks a GF(p) at random 2.Computes T A = g a mod p 3.Sends T A 4. Receives T B 5. Computes K A = T B a mod p. 1.Picks b GF(p) at random - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/1.jpg)
Security Services in Information Systems
![Page 2: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/2.jpg)
Basic Concepts
![Page 3: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/3.jpg)
Key exchange: Diffie-Hellman protocol
1. Picks a GF(p) at random
2. Computes TA = ga mod p
3. Sends TA
4. Receives TB
5. Computes KA = TBa mod p
1. Picks b GF(p) at random
2. Computes TB = gb mod p
3. Receives TA
4. Sends TB
5. Computes KB = TAb mod p
Where K = KA = KB, Because:
TBa = (gb)a = gba = gab = (ga)b = TA
b mod p
Machine A Machine B
![Page 4: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/4.jpg)
Man-in-the-Middle Attack
• After this exchange, the middle-person attacker simply decrypts any messages sent out by A or B, and then reads any possibly modifies them before re-encrypting with the appropriate key and transmitting them to the correct party.• Middle-person attack is possible due to the fact that DHC does not authenticate the participants. Possible solutions are digital signatures and other protocol variants.
• Consider the following scenario:
Anita Middleperson Betito
ga = 8389 gx = 5876 gb = 9267
8389 5876
5876 9267
Shared key KAX: Shared key KBX
5876a = 8389x 9267x = 5876b
![Page 5: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/5.jpg)
Mensaje en claro
Clave pública del destinatario
Mensajecifrado
Clave de sesión cifradaClave
de sesión
Se busca en el anillo de claves públicas del emisor
El documento se comprime antes con el algoritmo ZIP
Necesitamos una clave de sesión...
Cifrado con clave pública de destino [SItema16]
![Page 6: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/6.jpg)
Se busca en el anillo de claves privadas del receptor
Mensajecifrado
Clave de sesión cifrada
Clave privada destino cifrada
CONTRASEÑA
Clave privada descifrada
Clave de
sesión
Mensaje en claro
Descifrado con la clave privada de destino [SItema16]
![Page 7: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/7.jpg)
Key Distribution Problem[proposed solutions]
![Page 8: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/8.jpg)
Key Distribution/Management and Authentication
• two closely related subjects
• why?
![Page 9: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/9.jpg)
Key Distribution
• symmetric schemes require both parties to share a common secret key– issue is how to securely distribute this key without
revealing that key to an adversary
• many attacks are based on poor key management and distribution – rather than breaking the codes
• This is, actually, the most difficult problem in developing secure systems
![Page 10: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/10.jpg)
Key Distributionvarious key distribution alternatives for parties A and B :
1. A can select key and physically deliver to B– does not scale for a large and distributed group– how many keys do we need for N users?
2. third party can select & deliver key to A & B– similar comment as 1– sometimes finding a “trusted” third party is another problem
3. if A & B have communicated previously can use previous key to encrypt a new key
– good option but initially several keys to be distributed
4. if A & B have secure communications with a third party C, C can relay key between A & B
– only N master keys are enough
![Page 11: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/11.jpg)
Session Key / Master Key
• The idea is having a master encryption key (master key) to generate random and temporary session keys
• can be implemented in several ways– Basic D-H is such an example
• public/private keys are master keys, exchanged key is a session key
– Kerberos is another example– SSL uses three layers
• D-H for master key, master key for the session key
![Page 12: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/12.jpg)
Session Key / Master Key
• Session key lifetime is a trade-off– if small,
• more secure since attacker can obtain less ciphertext to analyze
• But this creates more delay
– If large• less secure, but less delay
![Page 13: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/13.jpg)
Key Distribution Facts
• Conservation of trust principle– a secure communication cannot be based on nothing;
either there should be an initial direct contact or an indirect one
• Either physical delivery or a trusted third party– physical delivery is the only option to avoid a third
party• most basic system is PIN entry• the case in Bluetooth
– otherwise regardless of symmetric or asymmetric encryption, you need a trusted third party
• even D-H does not work without a third party, why?
![Page 14: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/14.jpg)
A Key Distribution Example
• Symmetric crypto based• Each user shares a symmetric master key
with the KDC (Key Distribution Center)– e.g. Ka, Kb, Kc, …
– possibly physically distributed
• Basic idea:– whenever a user A wants to communicate with B,
it requests a session key (Ks) from KDC
• Protocol is in the next slide
![Page 15: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/15.jpg)
Nonce Definition
• Nonce: The present or particular occasion.
• Nonce word: A word occurring, invented, or used just for a particular occasion.
![Page 16: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/16.jpg)
A Key Distribution Example
![Page 17: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/17.jpg)
An Alternative
• In the previous figure, can KDC send message 3 directly to B?– If not, why?– If so, what are pros and cons?
![Page 18: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/18.jpg)
Hierarchies of KDCs
• we may have several KDCs connected to each other in a tree topology– each leaf KDC serves to a local community
• intra-domain communication passes thru only the local KDC, however inter-domain communication requires several KDC-KDC interaction
• master key delivery is only in local domains
![Page 19: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/19.jpg)
Decentralized Key Control
• We may avoid using KDC in a small group by having a master key for each pair
![Page 20: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/20.jpg)
Key Management in PKC
• In other words– distribution of public keys– use of PKC to distribute secret keys
• public/private key as a master key
![Page 21: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/21.jpg)
Distribution of the Public Keys
• the most important barrier against the deployment of PKC in applications
• Basic question?– how can I make sure about the legitimacy of a
public key? – how can I make sure that Bob’s public key really
belongs to Bob, not to Charlie?
• Why this is so important?– Name spoofing attacks become possible
• remember the man-in-the-middle attacks in anonymous Diffie-Hellman
![Page 22: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/22.jpg)
Distribution of the Public Keys
• Some methods– Public Announcement– Publicly available databases/directories– Centralized distribution– Certificates
![Page 23: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/23.jpg)
Public Announcement
• Broadcast your public key to the public– via newsgroups, mailing lists, from
personal website, etc.– major weakness is anyone can easily
pretend as yourself• so attacks are possible
![Page 24: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/24.jpg)
Publicly available directories/databases
• There exists a directory/database for {name, public key} pairs
• write controlled– a trusted administrator
• if administered thoroughly, good– but a proper administration is difficult
• need secure mechanisms for registration, update, delete.
![Page 25: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/25.jpg)
Centralized Distribution - Public-Key Authority
• Similar to directory/database approach, but access to the directory is automated via a secure protocol – users interact with directory to obtain any desired
public key securely– requires real-time access to directory when keys
are needed– users should know public key for the directory
• the directory/database contains {name, public key} pairs – write permit is restricted
![Page 26: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/26.jpg)
Centralized Distribution - Public-Key Authority PROTOCOL
![Page 27: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/27.jpg)
Centralized Distribution - Public-Key Authority
• Disadvantages– authority is an active entity and may create
a performance bottleneck– database should be kept secure to prevent
unauthorized modification
![Page 28: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/28.jpg)
Public-Key Certificates
• certificates allow key exchange without real-time access to public-key authority
• a certificate binds identity to public key – usually with other info such as period of validity, rights
of use, issuer’s info, etc
• all contents signed by a trusted Certification Authority (CA)
• can be verified by anyone who knows the CA public-key
• CA must make sure about the identity of the cert owner
![Page 29: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/29.jpg)
Public-Key Certificates
![Page 30: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/30.jpg)
Public-Key Certificates
• Certificates are widely used in practice– previous slides only show the idea
• need lots of polishing for practical use– is a single CA sufficient?– what happens if the CA’s public key is not known?
• how to distribute CA public keys?
– what happens if a certificate is revoked?
• We will discuss the use of certificates later
![Page 31: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/31.jpg)
What can you do with securely distributed public keys?
• Digital signatures– talked about them
• confidentiality– theoretically possible but slow– instead session keys can be distributed
• those session keys are used for symmetric encryption
![Page 32: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/32.jpg)
Distribution of Secret Keys using PKC
• Several methods exist
• Diffie-Hellman is one way
• we will see some alternatives
![Page 33: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/33.jpg)
Simple Secret Key Distribution
• proposed by Merkle in 1979– A generates a new temporary public key pair– A sends B its public key and identity– B generates a session key and sends it to A
encrypted using the supplied public key– A decrypts the session key and both use it
![Page 34: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/34.jpg)
Simple Secret Key Distribution
• problem is that an opponent can intercept and impersonate both halves of protocol– man-in-the-middle attack– result: A, B think that they exchanged Ks securely but C
also knows Ks and use it to eavesdrop the communication passively
CKUc
EKUc[Ks]EKUa[Ks]
![Page 35: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/35.jpg)
Public-Key Distribution of Secret Keys
• assumption: public-keys are securely exchanged a priori• First three steps are for authentication purposes• Last step provides both the secrecy and authenticity of
the session key
![Page 36: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/36.jpg)
In practice
• Most systems offer a three-level approach– use of PKC to exchange master-key– use of master-key to exchange session
keys
• most important advantage is at performance
![Page 37: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/37.jpg)
A closer look to authentication
• making sure of peer entity’s identity– mutual or one-way– non-repudiation is not an aim here
• generally implemented as a protocol– basic idea: making sure that other party knows a
common secret– also used for session key distribution
• two types– message authentication
• mostly one-way
– peer entity authentication• connection oriented approach
![Page 38: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/38.jpg)
Two key issues
• Protection of any secret information
• Timeliness– to prevent replay attacks
• a valid message is copied and later resent
– Why replays are bad?• at minimum, disrupt proper operation by
presenting messages that appear genuine but actually are not
• may also cause impersonation and key compromise
![Page 39: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/39.jpg)
Countermeasures - 1
• Sequence numbers– not a practical method– parties should keep track of the sequence
numbers– and should take care of message losses,
duplications in a secure manner• complicates stuff
![Page 40: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/40.jpg)
Countermeasures - 2
• Timestamps– message contains a timestamp– accepts only fresh messages based on this
timestamp– sometimes used but some practical
problems• clocks must be synchronized in a secure
manner (some attacks are merely based on failure on clock synchronization)
• tolerance to network delays
![Page 41: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/41.jpg)
Countermeasures - 3
• Challenge/response– Initiator sends a nonce (one-time challenge
phrase or number) and expects that nonce in the response
– easier to implement– but may require extra message transfer
![Page 42: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/42.jpg)
Authentication using Symmetric Encryption
• We start with well-known Needham-Schroeder protocol– actually have seen it as a key distribution protocol
• There exists a Key Distribution Center (KDC)– each party shares own master key with KDC– KDC generates session keys used for connections
between parties– master keys used to distribute these keys to them
![Page 43: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/43.jpg)
Needham-Schroeder Protocol• original three-party key distribution protocol
– for session between A and B mediated by a trusted KDC– KDC should be trusted since it knows the session key
• protocol overview1. A→KDC: IDA || IDB || N1
2. KDC→A: EKa[Ks || IDB || N1 || EKb[Ks||IDA] ]
3. A→B: EKb[Ks||IDA]
4. B→A: EKs[N2]
5. A→B: EKs[f(N2)]
• 4 and 5 are to prevent a kind of a replay attack– against replay of message 3 by an attacker
![Page 44: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/44.jpg)
Needham-Schroeder (NS) Protocol• but still vulnerable to a replay attack
– if an old session key has been compromised, then message 3 can be resent to B by an attacker X impersonating A
– after that X intercepts message 4 and send a message 5 to B as if it is A
– now X can impersonate A for the future communications with the session key
– unlikely but a vulnerability
• modifications to address this problem– timestamps (Denning 81), B contacted at the beginning
(Needham Schroeder 87)• see http://www.lsv.ens-cachan.fr/spore/index.html for a repository of security
protocols
![Page 45: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/45.jpg)
NS Protocol with timestamps• proposed by Dorothy Denning• A and B can understand replays by checking
the timestamp in the message– even if attacker knows Ks, he cannot generate
message 3 with a fresh timestamp since he does not know Kb
– open question: why do we need messages 4 and 5?
![Page 46: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/46.jpg)
Needham – Schroeder Protocol Revisited
• Amended by the creators themselves in 1987 by putting B in the loop early in the protocol
1. A -> B : A
2. B -> A : EKb[A, Nb]
3. A -> KDC : A, B, Na, EKb[A, Nb]
4. KDC -> A : EKa [Na, B, Ks, EKb [Ks, Nb, A]]
5. A -> B : EKb [Ks, Nb, A]
6. B -> A : Ks[Nb]
7. A -> B : Ks[f(Nb)]
![Page 47: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/47.jpg)
Synchronization problem• Proper use of timestamps requires synchronized
clocks• e.g. when sender’s clock is ahead of recipients
clock– attacker can intercept the message and replay later
• Neuman proposed use of nonces with timely session keys to constitute tickets in 93– nonces are used to avoid replays– timestamps are expiration dates of the session key
established– attacker only has a limited time to break the session key
• in original NS, attacker has unlimited time to break the session key
![Page 48: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/48.jpg)
Neuman Protocol
• EKb[IDA || Ks || Tb] is a ticket that can be used later within the limit of Tb
![Page 49: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/49.jpg)
Authentication using Public-Key Encryption
• We have given an example method that assumes public keys are known
• There exists protocols that also distributes public keys– using a central Authentication Server (AS)
or KDC– using timestamps or nonces
![Page 50: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/50.jpg)
One-Way Authentication
• required when sender & receiver are not online at same time – e-mail is a typical application– protocol should not rely on the processing of B
• A symmetric encryption approach1. A→KDC: IDA || IDB || N1
2. KDC→A: EKa[Ks || IDB || N1 || EKb[Ks||IDA] ]
3. A→B: EKb[Ks||IDA] || EKs[M]
• Provides authentication that the sender is A • does not protect against replays (of msg. 3)
– could rely on timestamp in message, but delays in email make this problematic
![Page 51: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/51.jpg)
Public-Key Approaches
• have seen some public-key approaches
• if confidentiality is major concern, can use:A→B: EKUb[Ks] || EKs[M]
– digital envelopes
• if authentication needed use a digital signature with a digital certificate:A→B: M || EKRa[H(M)] || EKRas[T||IDA||KUa]
– message, signature, certificate
![Page 52: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/52.jpg)
Overview on IP Security
![Page 53: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/53.jpg)
Internetwork Protocol (IP)
• Aim– provide interconnection across different
networks
• implemented in every network and in routers
• IP is an unreliable protocol– IP datagrams may be lost– IP datagrams may arrive out of order– TCP takes care of those problems
![Page 54: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/54.jpg)
Internetwork Protocol (IP)
![Page 55: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/55.jpg)
Where to provide security?
• Application-layer?– S/MIME, PGP – email security– Kerberos – client server– SSH – secure telnet
• Transport level?– SSL / TLS– between TCP and Application
• IP level– IPSec
![Page 56: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/56.jpg)
IPv4• The IP version that most LANs are
currently using
Data (Payload) follows the header
![Page 57: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/57.jpg)
IPv6
• Next generation IP– driving force was the inadequateness of IPv4
address space
• IPv6 header– modular approach– base header + extension headers– base header is longer than v4, but number of
fields is smaller
![Page 58: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/58.jpg)
IPv6 header
![Page 59: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/59.jpg)
Is IP Secure?
• Content (Payload) is not encrypted– confidentiality is not provided– IP sniffers are available on the net
• IP addresses may be spoofed– authentication based on IP addresses can be
broken
• So IP is not secure
![Page 60: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/60.jpg)
IPSec• general IP Security mechanisms• provides authentication and confidentiality at IP level
– also has key management features
• Applications– VPNs (Virtual Private Networks)
• Interconnected LANs over the insecure common carrier network (mostly the Internet)
• router-to-router
– Secure remote access, e.g. to ISPs• individual-to-router
• IPSec is mandatory for IPv6, optional for v4– many manufacturers support IPSec in their v4 products
![Page 61: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/61.jpg)
IPSec Application Scenarios
![Page 62: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/62.jpg)
AH – Anti-replay Service• Detection of duplicate packets • Sequence numbers
– associated with SAs – 32-bit value– when an SA is created, initialized to 0
• when it reaches 232-1, SA must be terminated• not to allow overflows
– sender increments the replay counter and puts into each AH (sequence number field)
• Problem: IP is unreliable, so the receiver may receive IP packets out of order– Solution is using windows
![Page 63: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/63.jpg)
AH – Anti-replay
Service
• If a received packet falls in the window– if authenticated and unmarked, mark it– if marked, then replay!
• If a received packet is > N– if authenticated, advance the window so that this packet is at the rightmost edge
and mark it
• If a received packet is <= N-W– packet is discarded; this is an auditable event
•Fixed window size W (default is 64)
–employed by the receiver
![Page 64: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/64.jpg)
Key Management in IPSec
• Ultimate aim– generate and manage SAs for AH and ESP– asymmetric
• receiver and initiator have different SAs
• can be manual or automated– manual key management
• sysadmin manually configures every system
– automated key management• on demand creation of keys for SA’s in large systems
![Page 65: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/65.jpg)
Key Management in IPSec• Complex system
– not a single protocol (theoretically)– different protocols with different roles
• intersection is IPSec• but may be used for other purposes as well
• Several protocols are offered by IPSec WG of IETF– Oakley, SKEME, SKIP, Photuris– ISAKMP, IKE
• IKE seems to be the IPSec key management protocol but it is actually a combination of Oakley, SKEME and uses ISAKMP structure
• See IPSec WG effort at http://www.ietf.org/html.charters/ipsec-charter.html
![Page 66: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/66.jpg)
Internet Key Exchange.
![Page 67: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/67.jpg)
X.509 Authentication
![Page 68: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/68.jpg)
X.509 Authentication Protocols
• X.509 is a ITU-T standard part of the “directory services”– mostly for certificates, but also propose
three generic authentication protocols– one-way authentication– two-way authentication– three-way authentication– use both nonces and timestamps
• nonces are unique only within the lifetime of timestamp
![Page 69: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/69.jpg)
X.509 one-way authentication• Proves that the message generated by A and
intended for B– also proves that message is not a replay– proves the identity of the sender, but not the recipient– optionally includes a session key
tA: timestamp rA: nonce sgnData: Data signed
![Page 70: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/70.jpg)
X.509 two-way Authentication• both parties verify identity of each other
• reply message– generated by B– not a replay (guaranteed by tB and rB)
![Page 71: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/71.jpg)
X.509 three-way Authentication• Nonces are signed and echoed back
– each side can check the replay– timestamps are not needed
• synchronized clocks are not needed either• what is a potential risk in such a case?
![Page 72: Security Services in Information Systems](https://reader035.vdocuments.mx/reader035/viewer/2022070406/5681407d550346895dac005d/html5/thumbnails/72.jpg)
X.509 Certificate Format