9
Initial Keying for KeySec John Viega, Russ Housley [email protected], [email protected]

Initial Keying for KeySec John Viega, Russ Housley [email protected], [email protected]

Embed Size (px)

Citation preview

Page 1: Initial Keying for KeySec John Viega, Russ Housley viega@securesoftware.com, housley@vigilsec.com

Initial Keying for KeySec

John Viega, Russ [email protected],

[email protected]

Page 2: Initial Keying for KeySec John Viega, Russ Housley viega@securesoftware.com, housley@vigilsec.com

• We know where we’re going on what to do once CAs have keys.

• Getting CA keys from pairwise keys is straightforward.

• Little work on initial keying for CA keys

• Channel for data– Meant for tunneling EAP, etc.

• Need simple, out of the box way to install keys

Progress in AF

Page 3: Initial Keying for KeySec John Viega, Russ Housley viega@securesoftware.com, housley@vigilsec.com

Use Case

• New device, need to set it up with pairwise key(s)

• Neighbors should be able to agree on pairwise keys with little manual intervention

• Would like a way to identify “my” devices and validate them.

Page 4: Initial Keying for KeySec John Viega, Russ Housley viega@securesoftware.com, housley@vigilsec.com

Proposal (1)

• Assign devices unique 128-bit IDs– Loaded with MAC address– 32 bits is a vendor identifier– 96 bits is vendor dependent, but must be unique

• Random number is perfectly fine– The idea: give IDs to devices as a simple ACL

Page 5: Initial Keying for KeySec John Viega, Russ Housley viega@securesoftware.com, housley@vigilsec.com

Proposal (2)

• Use RSA to validate device owns ID and exchange pairwise keys– Vendor generates and installs private key and

certificate w/ public key– Certificate is signed by a vendor’s signing

credentials– Vendor’s credentials are signed by a root

certification authority (CA)– IETF likely willing be that CA– CA would endorse vendor’s right to first 32 bits.– Vendor would endorse the validity of the

remaining bits.

• Net effect: unforgable credentials that facilitate enrollment

Page 6: Initial Keying for KeySec John Viega, Russ Housley viega@securesoftware.com, housley@vigilsec.com

Simple Public Key Infrastructure

n ...

RootCA

FirstVendor

CA

SecondVendor

CA

3 2DeviceCert 1

n ... 3 2DeviceCert 1

Page 7: Initial Keying for KeySec John Viega, Russ Housley viega@securesoftware.com, housley@vigilsec.com

Analysis

• Why not use MAC address?– MAC address forging is important to layer 2.– Devices may have many MAC addresses.

• Auxiliary benefits– Solves the layer 2 part of the ARP problem– Prevents counterfeiting hardware– Provides a basis for establishing trust in

firmware• Drawbacks

– Have to integrate with manufacturing process• Not costly• DOCSIS is doing something similar with cable modems

– Requires hash function for signing• Probably SHA1

Page 8: Initial Keying for KeySec John Viega, Russ Housley viega@securesoftware.com, housley@vigilsec.com

Example establishment protocol

• SignCrypt encrypts arg1, auths both args

• Unique ID is encoded into certificate

1. A-> A_cert, SignCrypt(Ra, 0) -> B2. A<- B_cert, SignCrypt(Rb,Ra) <- B3. A-> AID, SignCrypt(0, Rb) -> B

• Shared secret is Ra XOR Rb• All signatures and certs validated • IDs checked to ACL• On race, M1 from lower unique ID wins

Page 9: Initial Keying for KeySec John Viega, Russ Housley viega@securesoftware.com, housley@vigilsec.com

Summary

• Unique IDs on each device• Simple key management• Does not eliminate other

management methods– Credentials could be leveraged in centralized

management• Auxiliary benefits• Vendor must install keypair