Lecture 16: Security

Lecture 16: Security CDK4: Chapter 7 CDK5: Chapter 11 TvS: Chapter 9

Security in 1 machine Within 1 machine, the OS is responsible for • Verifying users’ identities • Checking access rights to shared objects Not too difficult! But a network brings new problems: • Different machines – identity mapping • Network weaknesses …. COMP28112 Lecture 16

Security Problems of the Network Messages can be: • Read => loss of secrecy/privacy • Altered • Created containing forged information • Copied and replayed Can also have denial of service attacks COMP28112 Lecture 16

Cryptography All the problems with messages find solutions based on • The inclusion (and checking) of extra information (e.g. sequence nos.) and • Encryption • Using some algorithm, plaintext is converted to encrypted text COMP28112 Lecture 16

Secure Channels • How to make client-server communication secure? • 1. Authentication of the communicating parties. We may need to ensure message integrity, confidentiality, etc. • 2. Authorization. Is the client authorized to have that request carried out? Relates to controlling access to the resources (granting access rights). • A secure channel (Voydock and Kent, 1983) protects senders and receivers against interception, modification and fabrication of messages. COMP28112 Lecture 16

Properties of Secure Channels A secure channel connects two processes and: • Ensures each process knows reliably the identity of the principal on whose behalf the other process is acting • Each message includes a physical or logical time stamp to prevent replay or reordering COMP28112 Lecture 16

Digital Signatures • Need an electronic version of a signature to authenticate a message • Unlike paper signatures, we need to stop a signature being attached to other messages by cutting and pasting! So a signature will include the message or a secure digest derived from the signed message. COMP28112 Lecture 16

Secure digests • A digest is also called a secure hash function. • Need to be sure that, given the digest value, the receiver cannot invent another message which yields the same digest value! COMP28112 Lecture 16

Uses of signatures There are two aspects: • Authentication – receiver knows that the message is from the signer, because it is assumed impossible to forge a signature • Non-repudiation – the sender can’t deny sending the message COMP28112 Lecture 16

Keys in Cryptography Two kinds: • Shared secret keys – the major problem is how to establish a shared secret key between principals who never meet! • Public/private key pairs – every one has such a pair; everyone knows all the public keys, only the principal knows the private. Need other key to decrypt message. COMP28112 Lecture 16

Public key encryption • Requires 100 – 1000 times as much processing power as secret-key algorithms • Rely on the “impossibility” of deriving the private key from the public one COMP28112 Lecture 16

Pragmatics • Better not to rely on secrecy of encryption algorithms – in practice clients and servers need to know, or even negotiate, these – rely only on keys • Bigger keys take longer to crack – but it is often just a matter of time, and the timescale gets shorter as attackers get more powerful computers COMP28112 Lecture 16

Sending a confidential message • A -> B: Message encrypted with B’s public key • Only B can decrypt OR (more practically) • A -> B: 1-off session key, K, encrypted with B’s public key • A -> B: Message encrypted with K COMP28112 Lecture 16

Digital Signature with Public Keys • A -> B: A’s identity, and the message encrypted with A’s private key • B can decrypt using A’s public key – and the fact that this works proves that A encrypted it – as only A knows that key. • To keep the above confidential, A could encrypt the whole with B’s public key! COMP28112 Lecture 16

Key distribution • Need a way to get the public keys • This needs to be secure – e.g. if an enemy intercepts the request for a key, it can reply with one it invented • On an intranet, we can design a simple protocol for an authentication server COMP28112 Lecture 16

Digital Certificates • In the wider world, we need to be able to be sure that servers (and clients) are who they claim to be (and give their public keys). • A certificate is an unforgeable document issued by a more trustworthy source • Thus a certification chain is established • Revocation – hard, use expiry date COMP28112 Lecture 16

Needham-Schroeder Authentication Protocol • Designed for use with an authentication server, S, which has secret keys for all principals • How to get two processes, A and B, communicating securely without revealing secret keys to each other • Used in Kerberos (within Intranets) COMP28112 Lecture 16

KA Alice’s secret key KB Bob’s secret key KAB Secret key shared between Alice and Bob KApriv Alice’s private key (known only to Alice) KApub Alice’s public key (published by Alice for all to read) { M } K Message M encrypted with key K [ M ]K Message M signed with key K Cryptography notations COMP28112 Lecture 16

The Needham–Schroeder secret-key authentication protocol (7.14 in CDK) Header Message Notes 1. A->S: A requests S to supply a key for communication A, B, NA with B. S returns a message encrypted in A’s secret key, 2. S->A: {NA , B, KAB, containing a newly generated key KAB and a {KAB, A}KB}KA ‘ticket’ encrypted in B’s secret key. The nonce NA demonstrates that the message was sent in response to the preceding one. A believes that S sent the message because only S knows A’s secret key. A sends the ‘ticket’ to B. {KAB, A}KB 3. A->B: B decrypts the ticket and uses the new key KAB to {NB}KAB 4. B->A: encrypt another nonce NB. A demonstrates to B that it was the sender of the {NB - 1}KAB 5. A->B: previous message by returning an agreed transformation of NB. COMP28112 Lecture 16

The same also from TvS (Fig 9.17) COMP28112 Lecture 16

Summary • Whole 3rd year course on using Cryptography in Networks …. • This lecture has only scratched the surface – read Chapter 7 of CDK4 or Chapter 11 of CDK5 or Chapter 9 of TvS if you are interested. COMP28112 Lecture 16

Lecture 16: Security