Transcript Lightweight Security Protocols for Consumer Electronics Devices Dr. James W. Gray, III Security Architect Outline • Background – An Example Protocol (MS CHAP v2) – Goals of the Present.

Lightweight Security
Protocols for Consumer
Electronics Devices
Dr. James W.
Gray, III
Security
Architect
Outline
• 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
Copyright 1999 RSA Data Security, Inc.
3
Microsoft’s CHAP (version 2)
(Nov. 1998; work in progress)
RS
Client
M1=MAC(K, RC.RS.C) . RC
K
RS
RC
MAC(K, RC.RS.M1)
Server
K
RS
RC
For MS CHAP v2, MAC(K,m) involves
DES, MD4, and SHA-1.
Copyright 1999 RSA Data Security, Inc.
4
MS-CHAP (v2) MAC Response
Password
RC.RS.C
MD4
16 Bytes
Zero Pad
21 Bytes
SHA-1
20 Bytes
Truncate
8 Bytes
3-way Split
7 Bytes
DES
DES
DES
24-Byte Concatenated Response
Copyright 1999 RSA Data Security, Inc.
5
(Apparent) Design Goals of
Microsoft’s VPN Solution
(PPTP)
• Mutual Authentication
• Replay Prevention
• Session Key Secrecy
There is a oneto-one
correspondence
between clients
and servers.
After the handshake, messages can
be sent (in either direction) encrypted.
Copyright 1999 RSA Data Security, Inc.
6
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)
Copyright 1999 RSA Data Security, Inc.
7
The Embedded Market
Enable new devices . . .
– Two-Way Pagers
– Wireless Phones
– Personal Data Assistants (PDAs)
. . . with new applications
– Web Commerce
– Remote Access
– Financial Transactions
Copyright 1999 RSA Data Security, Inc.
8
Constrained Resources for
Embedded Systems
•
•
•
•
•
Processing power
Static storage space (typically ROM)
Runtime storage space (typically RAM)
Communications bandwidth
Battery life
Copyright 1999 RSA Data Security, Inc.
9
Cryptographic Building Blocks
Asymmetric (Public Key) Cryptography:
• RSA:
– cheap public-key operations (encryption
and signature verification);
– expensive private-key operations
(decryption and signing)
• Elliptic Curve Cryptography (ECC):
– all operations moderately-cheap
Copyright 1999 RSA Data Security, Inc.
10
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.
Copyright 1999 RSA Data Security, Inc.
11
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.
Copyright 1999 RSA Data Security, Inc.
12
More General Strategies
• Define lightweight formats, e.g., for
certificates.
• Engineer a lightweight suite of
cryptographic tools.
Copyright 1999 RSA Data Security, Inc.
13
BSAFE Crypto Compact
Design Goals
From April 1998:
• 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)
Copyright 1999 RSA Data Security, Inc.
14
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].
Copyright 1999 RSA Data Security, Inc.
15
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.
Copyright 1999 RSA Data Security, Inc.
16
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.
Copyright 1999 RSA Data Security, Inc.
17
The Crypto-Compact
Lightweight Messaging
Protocol
RC
MAC(K, RC.RS.C.S) . RS
Client
MAC(K, RC.RS.S.C)
K
RC
RS
Server
K
RC
RS
Session key = KDF(K, RC . RS)
Copyright 1999 RSA Data Security, Inc.
18
Key Separation
K is not used directly. Rather, to avoid
insecure interactions, various keys are
“derived” from K for different uses:
•
•
•
•
•
Client-side handshaking
Client-side message encryption
Client-side message authentication
Server-side handshaking
etc . . .
Copyright 1999 RSA Data Security, Inc.
19
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.)
Copyright 1999 RSA Data Security, Inc.
20
MS-PPTP vs Crypto-Compact
LWMP
• MS-PPTP uses an ad hoc response;
Crypto Compact uses the provablysecure RC5-DMAC.
• With MS-PPTP, every password is
breakable in O(256) operations.
• In MS-PPTP, session data is not
integrity-protected.
Copyright 1999 RSA Data Security, Inc.
21
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.
Copyright 1999 RSA Data Security, Inc.
22
Improving Key Management
Cert(KCA-1, S.KS)
Client
Encrypt(KS.K)
Server
KS , KS-1
Cert(KCA-1, S.KS)
KCA
KS
K
K
K is established for future use.
Copyright 1999 RSA Data Security, Inc.
23
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.
Copyright 1999 RSA Data Security, Inc.
24
Secure OTAP
Possible approaches include:
• Symmetric-key-based protocols
• Public-key-based protocols
Copyright 1999 RSA Data Security, Inc.
25
Symmetric-Key-Based OTAP
Conf | N | mac
Client
Server
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
Copyright 1999 RSA Data Security, Inc.
26
Advantages of SymmetricKey-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.
Copyright 1999 RSA Data Security, Inc.
27
Disadvantages of SymmetricKey-Based OTAP
• For “deactivation”, this protocol is
vulnerable to “blocker” attacks.
• Shared key management is expensive
and a potential security risk.
Copyright 1999 RSA Data Security, Inc.
28
Public-Key-Based OTAP
Conf | N | S | sig
Client
Server
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
Copyright 1999 RSA Data Security, Inc.
29
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.
Copyright 1999 RSA Data Security, Inc.
30
Secure Broadcast
• Pay per view
• Monthly subscriptions
• “Deactivation” (when the customer
stops paying) is crucial.
Copyright 1999 RSA Data Security, Inc.
31
A Secure Broadcast Protocol
• Assumptions:
– Service Provider (SP) manages (physically
secure) local access points.
– Two-way communication is possible.
Copyright 1999 RSA Data Security, Inc.
32
A Secure Broadcast Protocol
• Approach: Enhance the secure OTAP
protocol to install a temporary (shared
secret) broadcast key into selected
devices.
Copyright 1999 RSA Data Security, Inc.
33
A Secure Broadcast Protocol
S
Local
Access
Client
Point
E = Encrypt(Ks, Kb) = Encrypted broadcast key
N = 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
E | N | mac
Copyright 1999 RSA Data Security, Inc.
34
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.
Copyright 1999 RSA Data Security, Inc.
35
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.
Copyright 1999 RSA Data Security, Inc.
36
Conclusions?
Copyright 1999 RSA Data Security, Inc.
37