1. Security Services in Information Systems

2. Basic Concepts

3. 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
Machine A
Machine B
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 = TAb mod p

4. Man-in-the-Middle Attack
Consider the following scenario:
Anita Middleperson Betito
ga = gx = gb = 9267
Shared key KAX: Shared key KBX
5876a = 8389x x = 5876b
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.

5. Cifrado con clave pública de destino [SItema16]
Mensaje en claro
Mensaje
cifrado
El documento se comprime antes con el algoritmo ZIP
Necesitamos una clave de sesión...
Clave de sesión cifrada
Clave de sesión
NOTAS SOBRE EL TEMA:
Se busca en el anillo de claves públicas del emisor
Clave pública del destinatario

6. Descifrado con la clave privada de destino [SItema16]
Mensaje
cifrado
Mensaje en claro
Clave de sesión cifrada
Clave de sesión
NOTAS SOBRE EL TEMA:
Clave privada destino cifrada
Clave privada descifrada
Se busca en el anillo de claves privadas del receptor
CONTRASEÑA

7. Key Distribution Problem [proposed solutions]

8. Key Distribution/Management and Authentication
two closely related subjects
why?

9. 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

10. Key Distribution
various key distribution alternatives for parties A and B :
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?
third party can select & deliver key to A & B
similar comment as 1
sometimes finding a “trusted” third party is another problem
if A & B have communicated previously can use previous key to encrypt a new key
good option but initially several keys to be distributed
if A & B have secure communications with a third party C, C can relay key between A & B
only N master keys are enough

11. 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

12. 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

13. 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?

14. 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

15. Nonce Definition Nonce: The present or particular occasion.
Nonce word: A word occurring, invented, or used just for a particular occasion.

16. A Key Distribution Example

17. An Alternative
In the previous figure, can KDC send message 3 directly to B?
If not, why?
If so, what are pros and cons?

18. 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

19. Decentralized Key Control
We may avoid using KDC in a small group by having a master key for each pair

20. 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

21. 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

22. Distribution of the Public Keys
Some methods
Public Announcement
Publicly available databases/directories
Centralized distribution
Certificates

23. 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

24. 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.

25. 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

26. Centralized Distribution - Public-Key Authority PROTOCOL

27. 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

28. 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

29. Public-Key Certificates
Stallings Fig See text for details of steps in protocol.

30. 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

31. 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

32. Distribution of Secret Keys using PKC
Several methods exist
Diffie-Hellman is one way
we will see some alternatives

33. 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

34. 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
KUc C
EKUa[Ks]
EKUc[Ks]

35. 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

36. 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

37. 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

38. 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

39. 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

40. 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

41. 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

42. 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

43. 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 overview
1. 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

44. 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 for a repository of security protocols

45. 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?
messages 4 and 5 are needed to confirm the receipt of the session key at B

46. 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)]

47. 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

48. Neuman Protocol
EKb[IDA || Ks || Tb] is a ticket that can be used later within the limit of Tb

49. 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

50. One-Way Authentication
required when sender & receiver are not online at same time
is a typical application
protocol should not rely on the processing of B
A symmetric encryption approach
1. 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 make this problematic

51. 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

52. Overview on IP Security

53. 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

54. Internetwork Protocol (IP)

55. Where to provide security?
Application-layer?
S/MIME, PGP – security
Kerberos – client server
SSH – secure telnet
Transport level?
SSL / TLS
between TCP and Application
IP level
IPSec

56. IPv4 The IP version that most LANs are currently using
Data (Payload) follows the header

57. IPv6 Next generation IP IPv6 header
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

58. IPv6 header

59. 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

60. 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

61. IPSec Application Scenarios

62. 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

63. AH – Anti-replay Service
Fixed window size W (default is 64)
employed by the receiver
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

64. 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

65. 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

66. Internet Key Exchange.

67. X.509 Authentication

68. 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

69. 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

70. 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)

71. 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?

72. X.509 Certificate Format