Lightweight Security Protocols for Consumer Electronics Devices Dr. James W. Gray, III Security Architect RSA Laboratories

Copyright 1999 RSA Data Security, Inc.

Copyright 1999 RSA Data Security, Inc.

Lightweight Security Protocols for Consumer Electronics Devices

Dr. James W. Gray, IIISecurity

ArchitectRSA

Laboratories

Copyright 1999 RSA Data Security, Inc. 3

• Background– An Example Protocol (MS CHAP v2)– Goals of the Present Work– Cryptographic Building Blocks

• General Strategies

• A New Secure Remote Access Protocol

• Other Protocols

• Conclusions

Outline


Microsoft’s CHAP (version 2) (Nov. 1998; work in

progress)

For MS CHAP v2, MAC(K,m) involves DES, MD4, and SHA-1.

RS

MAC(K, RC.RS.M1)Client Server

K K

RSRS

RCRC

M1=MAC(K, RC.RS.C) . RC


MS-CHAP (v2) MAC Response

MD4

Zero Pad

Password

3-way Split

RC.RS.C

SHA-1

Truncate

DES DES DES

24-Byte Concatenated Response

8 Bytes

16 Bytes

21 Bytes

7 Bytes

20 Bytes


(Apparent) Design Goals of Microsoft’s VPN Solution

(PPTP)

• Mutual Authentication

• Replay Prevention

• Session Key Secrecy

After the handshake, messages can be sent (in either direction) encrypted.

There is a one-to-one correspondence between clients and servers.


Required Primitives for MS PPTP

• MD4 (response MAC)

• SHA-1 (response MAC)

• DES (response MAC)

• RC4 (MPPE bulk encryption)

• Others? (Key derivation and random number generation)


The Embedded Market

– Two-Way Pagers– Wireless Phones– Personal Data Assistants (PDAs)

Enable new devices . . .

– Web Commerce– Remote Access– Financial Transactions

. . . with new applications


Constrained Resources for Embedded Systems

• Processing power

• Static storage space (typically ROM)

• Runtime storage space (typically RAM)

• Communications bandwidth

• Battery life


Cryptographic Building Blocks

• RSA: – cheap public-key operations (encryption

and signature verification);– expensive private-key operations

(decryption and signing)

• Elliptic Curve Cryptography (ECC): – all operations moderately-cheap

Asymmetric (Public Key) Cryptography:


More Cryptographic Building Blocks

• Block ciphers (RC2, RC5, DES, …)• Stream ciphers (RC4)• Cryptographic hash functions (MD5, SHA-

1)

The above are typically much faster (to compute) than asymmetric primitives.


General Strategies

• Offload computation to the server.

• Favor symmetric cryptography over asymmetric cryptography.

• When using asymmetric cryptography:– If private-key operations can be avoided

on the client side, use RSA.– When private-key operations are necessary

on the client side, use ECC.


More General Strategies

• Define lightweight formats, e.g., for certificates.

• Engineer a lightweight suite of cryptographic tools.


BSAFE Crypto Compact Design Goals

• Mutual Authentication, Replay Prevention, Session Key Secrecy

• No asymmetric cryptography

• Bulk data privacy and integrity

• A single primitive (e.g., RC4, RC5, or SHA-1)

From April 1998:


Which Primitive?

• Encrypting with a Hash is dubious.

• Message authentication with a stream cipher is not (yet?) well-understood.

• Block ciphers are likely candidates [Bellare and Rogaway’s provable security results].


How do you MAC with a Block Cipher?

• Bellare and Rogaway’s constructions require the implementation to know the length of the message prior to computing the MAC.

• DMAC [Petrank and Rackoff] is provably secure and avoids the difficulties with B&R’s schemes.


A Compact Cryptographic Toolkit

• RC5 (CBC-mode) encryption

• RC5 DMAC message authentication

• RC5-based pseudo random number generation

• RC5-based key derivation

The above are implemented in BSAFE Crypto Compact using about 20K of code space.


The Crypto-Compact Lightweight Messaging

Protocol

Session key = KDF(K, RC . RS)

RC

MAC(K, RC.RS.S.C)Client Server

K K

RCRC

RSRS

MAC(K, RC.RS.C.S) . RS


Key Separation

• Client-side handshaking• Client-side message encryption• Client-side message authentication• Server-side handshaking• etc . . .

K is not used directly. Rather, to avoid insecure interactions, various keys are “derived” from K for different uses:


More on Crypto-Compact LWMP

• Pros:– successfully deals with all of our general

technical goals;– Built on provably-secure constructions;– implemented in 25 K.– Great for constrained devices.

• Con: – Key management. (Public-key technology

is the solution here.)


MS-PPTP vs Crypto-Compact LWMP

• MS-PPTP uses an ad hoc response; Crypto Compact uses the provably-secure RC5-DMAC.

• With MS-PPTP, every password is breakable in O(256) operations.

• In MS-PPTP, session data is not integrity-protected.


MS-PPTP vs Crypto-Compact LWMP

• MS-PPTP requires MD4, SHA-1, DES, and RC4; Crypto Compact only requires RC5.

• MS-PPTP’s random number generation is unspecified; Crypto Compact performs it in a secure manner.


Improving Key Management

K is established for future use.

Cert(KCA-1, S.KS)

Client Server

KCA KS , KS-1

Encrypt(KS.K)

Cert(KCA-1, S.KS)

K K

KS


Secure Over-The-Air Programming (OTAP)

• Pagers, wireless phones, and other wireless devices need to be securely configured by the service provider (SP).– SP controls when the device is allowed to

switch to a new provider.– SP controls the set of “channels” or

services that the device receives.


Secure OTAP

• Symmetric-key-based protocols

• Public-key-based protocols

Possible approaches include:


Symmetric-Key-Based OTAP

Client ServerConf | N | mac

Conf = the new configuration;N = a sequence number;mac = MAC(K, Conf | N), K = device-specific long-term shared-secret key.

If (N > last && mac-verify) Client updates its configuration


Advantages of Symmetric-Key-Based OTAP

• Changes to a new Service Provider (SP) authorized only by the current SP. (Churn is prevented.)

• Only the legitimate SP can “activate” channels and services.

• Sequence numbers prevent replay attacks.


Disadvantages of Symmetric-Key-Based

OTAP

• For “deactivation”, this protocol is vulnerable to “blocker” attacks.

• Shared key management is expensive and a potential security risk.


Public-Key-Based OTAP

Client ServerConf | N | S | sig

Conf = the new configuration;N = a sequence number;S = the client’s serial number;sig = RSA(Sk, Conf | N | S); Sk = Server’s private key.

If (N > last && signature-verify && S = Client) Client updates its configuration


More on Public-Key-Based OTAP

• Advantages:– No secrets are stored on the device, so

reading the device memory does not compromise security.

– Devices are personalized only by their serial number, which is cheaper than personalizing with a shared secret key.

• Using RSA, the client computes only a (cheap) signature verification.


Secure Broadcast

• Pay per view

• Monthly subscriptions

• “Deactivation” (when the customer stops paying) is crucial.


A Secure Broadcast Protocol

• Assumptions:– Service Provider (SP) manages (physically

secure) local access points.– Two-way communication is possible.



• Approach: Enhance the secure OTAP protocol to install a temporary (shared secret) broadcast key into selected devices.



Client

Local Access Point

E | N | mac

S

E = Encrypt(Ks, Kb) = Encrypted broadcast keyN = a sequence number;S = the client’s serial number;mac =MAC(Ks, E | N | S); Ks = device-specific long-term shared-secret key.If (N > last && mac-verify)

Client decrypts E and installs Kb


Secure Broadcast Protocol - Discussion

• Kb is unique to the local access point.

• Local access point contacts central server to:– obtain Client’s long-term key Ks;– ensure Client obtains at most one key Kb.


Secure Broadcast Protocol - Discussion

• Reading a long-term key for a legitimate client, say S, allows an attacker to, at most, obtain broadcast keys for pirate devices (clones of S) on the same local access point as S. Thus, large-scale piracy is defeated.


Conclusions?

Documents

Lightweight Security Protocols for Consumer Electronics Devices Dr. James W. Gray, III Security Architect RSA Laboratories