Protocol Building Blocks

1. Protocols are multi-agent algorithms

2. Agents know protocol

3. Protocol unambiguous, well-defined

4. Protocol complete, action for any situation

5. Effects limited: can’t do or learn more than protocol specifies

Personalities

1. Alice, Bob, Carol: agents in protocol

2. Eve: eavesdropper

3. Mallory: malicious active attacker

4. Trent: trusted arbitrator

5. Walter: warden to guard A and B

6. Peggy: prover

7. Victor: verifier

Some Protocol Types

1. Arbitrated: trusted 3rd party, maybe computer, in middle. Bottleneck and weakpoint.

2. Adjudicated: executed when there is a dispute.

3. Self-enforcing: guarantees fairness, no disputes, cheating, etc.

Protocol Attacks

1. Attack encryption, algorithm implementations, or protocols.

2. Eavesdropping is a passive attack to gain information -- hard to detect.

3. Active attacks alter protocols, introduce, delete, replay, substitute msgs, impersonate, disrupt, alter.

4. If party attacks protocol, he’s a cheater (active or passive).

Symmetric Key Communication

1. A and B agree on Encryption and Key

2. A encrypts msg with key

3. A sends ciphertext to B

4. B decrypts with key and algorithm.

Symmetric Key Communications Attacks

1. Eve wants to hear key selection and algorithm as well as msg. Key management is big topic

2. Mallory could break cipher, break comm. Channel, replace msgs…

3. Alice could give copy of key to Eve, or copy Bob’s msgs to NY Times…trust!

4. Losing key disastrous.

One Way Function

1. Easy to compute but hard to invert

2. Trapdoor one-way fns have secret key to make inversion easy.

One-way Hash Functions

1. Also called compression fn, checksum, message integrity check.

2. Maps variable-length pre-image to fixed-length hash value…e.g XOR of all input bytes.

3. One-way hash hard to find pre-image for that hash value.

4. Best if no collisions…could verify files same without sending them.

Comms with PK Crypto

1. A and B agree on cryptosystem

2. B sends A his public key

3. A encrypts msg with that key, sends to B.

4. B decrypts with private key.

5. No key management: Asymmetric cryptosystem. Often a database of public keys.

Hybrid Cryptosystems

1. B sends A his private key.

2. A generates random session key K, encrypts with B’s public key, sends to B.

3. B decrypts with his private key, gets K.

4. A and B now use K to encrypt comms

5. No symmetric key sits around long

6. Faster!

Digital Signatures

1. Authentic, Convincing, unforgeable, not reusable, unalterable, non-repudiatable (ideally) (as in seismometers for test-ban compliance monitoring).

Symmetric Ciphers and Arbitrator

1. Trent shares KA with Alice, KB with Bob.

2. A encrypts msg to B with KA, sends to Trent.

3. Trent decrypts msg with KA

4. T encrypts msg, stmt it’s from A thru T, using KB and sends the bundle to B.

5. B decrypts all with KB. Has msg, certification.

Observations on Symm.+Trent

1. T knows msg is from A since her key worked.

2. If B takes T’s certification and pastes it onto another msg “from A” -- B is impersonating T. B can’t supply info justifying his msg (see notes).

3. To forward msg to C need T again. How would you automate T? Security of signature database?

Signing with PK

1. A encrypts doc with her private key, thus “signing” it.

2. A sends signed doc to B.3. B decrypts doc with A’s public key,

thus verifying signature.4. Signature not reusable since mixed in

with doc by the cryptosystem. Altering doc. means it won’t be verified by PK. Timestamps kill future use. Other criteria OK too (check!)

Signing with PK and Hash

1. Why encrypt whole doc?

2. A and B agree on one-way hash fun, signature algorithm

3. A encrypts hash of doc. with her private key. This is signature.

4. A sends doc and signed hash to B

5. B produces hash of doc, decrypts signed hash with A’s public key. If match, valid and signed.

More on signing with hash

1. Here signature separate from doc, so smaller storage requirements.

2. Archive could just store hash, not doc. Can verify you have right doc by comparing hashes.

3. So timestamp +hash means you could copyright document you keep secret!

Multiple Signatures

1. A and B sign separate copies…bulky!

2. OR, A signs, B signs A-signed doc. OK but have to verify both if want to verify A’s sig.

3. One-way hash: A, B sign hash of doc.

4. B sends signature to A

5. A sends doc. and 2 sigs to C

6. C verifies A’s or B’s sig or both.

Repudiation

1. A can repudiate a signature. After signing, she publishes her private key on ur.general and claims it was stolen.

2. Timestamps can help

3. Private keys residing in tamper-proof modules can help.

4. Old signatures should not be invalidated by disputes about recent ones….use Trent.

Digital Signatures & Encryption:envelope & sig

1. A signs msg with private key: SA(M).2. A encrypts signed msg with B’s PK

and sends it to him: EB(SA(M))3. B decrypts with private key:

DB(EB(SA(M))) = SA(M)4. B verifies with A’s public key.5. Different encryption and signing keys

make sense: can give up one w/o losing the other.

6. Timestamps can ack receipt.

Signatures and Verification

1. A signs, encrypts: EB(SA(M)).

2. B decrypts, verifies: VA(DB(EB(SA(M)))) = M

3. Bob signs M with his PK, encrypts with A’s PK and sends back: EA(SB(M)).

4. Alice decrypts, verifies B’s sig with his PK, sees its him and he sent back same msg she sent.

Resend Attack

1. If same alg. For encryption and sigs…2. Mallory in system with own public and

private keys.3. He intercepts and records A’s msg to B. 4. Later he sends it to B, claiming it came

from Mallory. Bob decrypts etc. with M’s keys but gets rubbish: EM(DB(EB(DA(M)= EM(DA(M)).

5. BUT he (or his “secure comm. Script”) continues….

Resend Attack Continued

1. So Bob continues, sending Mallory a receipt: EM(DB(EM(DA(M))))

2. So now M just needs to decrypt with his own key, encrypt with B’s PK, decrypt with his key again, Encrypt with A’s PK, and he’s got M.

3. Foil with != keys for sig, encrypt. Or timestamps so incoming, outgoing msgs ae different, or use hashes.

Public Key Management

1. Need write-protected (but for Trent) public database (don’t want people substituting their keys for yours).

2. M substitutes during transmission?3. T signs each PK with his private key.

Then he’s a Key Dist. Ctr. Or Key Cert. Authority.

4. If A stores the KDC’s public key, suppose M substituted his own PK for it? He could impersonate KDC.

Random Numbers

1. Knuth Vol 2. Still a good reference!

2. Test your favorite RNG…about same number of each digit (1,0), about half the runs of 1 or 0 should be of length 1, 1/4 of length 2, etc. Should not compress.

3. Finite state implies pseudorandom sequence. 2256 bit periods are possible.

4. Cryptographically secure: unpredictable given algorithm and all previous bits.