Alice and Bob get Physical: Introducing Physical Contexts into

Security for the Future Internet

Wade Trappe

[1]

Obligatory disclaimer: Although I am a member of the Mobility First “Future Internet Team,” this talk does not represent the views of Mobility First and may include radical views that could lead to excommunication by my colleagues.Second disclaimer: This talk is somewhat wireless-centric… what would the Internet be without wireless???

WINLAB

The current network is plagued with numerous examples of exploits, phishing, malware, etc.

DNS Exploits:

– Kaminsky’s 2008 DNS Cache Poisoning

– Kaminsky discovered a way to combine the QID weakness with bailiwick

spoofing to poison caches.

Prefix Hijacking:

– Victim owns a prefix, you claim to own that same prefix

– Examples:

(2008) Youtube prefix hijacked by Pakistan Telecom

(2006) Sprint announced TTNET as the origin AS for 4/8, 8/8, 12/8

VeriSign issued Class 3 code-signing digital certificates to an individual who

fraudulently claimed to be a Microsoft employee.

– Common name assigned to both certificates is "Microsoft Corporation."

– Ability to sign executable content by using keys that purport to belong to

Microsoft would convince users to allow false content to run

– VeriSign updated its Certificate Revocation list (CRL), but VeriSign code-

signing certificates do not specify a CRL Distribution Point (CDP), so a browser

would not know where to check.

[2]

WINLAB

Generic examples of security flaws in real systems illustrates the challenge of getting security right

Prepayment in Electricity Meter Systems:

– Present a (purchased) digital token to a power meter.

– Digital token would convey an ID so it could not be duplicated or forged…

– Problem was that the rate information was not protected

Bank Fraud:

– A bank would allow customers to present a bank card which had a PIN code encrypted and stored on the magnetic strip

– Teller had a copy of the encryption key and could check the PINs.

– Flaw in design: adversary could alter the account number on the card to someone else’s, while using his own PIN number… he would check out ok… but the money would be drawn from someone else’s account!

– Flaw in design: PIN number was not connected to account #.

WINLAB

Wireless systems have not faired well in terms of security design

Cellular Message Encryption Algorithm (CMEA) was deeply flawed

802.11 systems, when originally deployed:

– Were shipped with security disabled

– Offered SSID/MAC address filtering as security

– WEP was seriously flawed

Routing protocols are hard to get right

– AODV is inherently insecure

– Its secure variants (ARAN, SAODV) have not done much better

The wireless medium is inherently more challenging

– Eavesdropping is trivial and impossible to detect

– Open, broadcast medium

Jamming is possible

The wireless product space is more diverse

– Highly programmable platforms available

– Easy to create one’s own device and use it

WINLAB

Cellular security algorithms were poorly designed, leading to numerous attacks

The Telecommunications Industry Association proposed four cryptographic primitives for use in North America (1995, all are now considered weak):

– CAVE: A mixing function used for authentication and key generation

– XOR masking used for voice privacy

– ORYX: an LFSR-based stream cipher

– CMEA (Control Message Encryption Algorithm): a block cipher to encrypt control channel

Consider CMEA:

– CMEA is its own inverse (every key is a “weak key”)

– CMEA encrypts short blocks, but cellular telephony did not employ CFB, or random IVscodebook attacks are a threat (consider there are only 10 digits!)

– LSB of plaintext is leaked

– Internal T-box has skewed statistical distribution (reduces search space significantly)

– Chosen-plaintext attack can succeed with 338 chosen plaintexts and very little work

– Known plaintext attacks: 3-byte version succeeds with 80 known texts and ~232 complexity; 2-byte attacks only need 4 known plaintexts (undermining IS-95)

Compromise of control channel can lead to compromise of confidential information shared over control channel:

– PIN numbers, credit card numbers, bank account information

– Digits dialed by users might reveal user calling patterns

WINLAB

Early 802.11 proposed WEP to address security concerns, but design was inherently weak

Designed to provide confidentiality to a wireless network similar to that of standard

LANs.

WEP is essentially the RC4 symmetric key cryptographic algorithm (same key for

encrypting and decrypting).

– Transmitting station concatenates 40 bit key with a 24 bit Initialization Vector (IV) to

produce pseudorandom key stream.

– Plaintext is XORed with the pseudorandom key stream to produce ciphertext.

– Ciphertext is concatenated with IV and transmitted over the Wireless Medium.

– Receiving station reads the IV, concatenates it with the secret key to produce local

copy of the pseudorandom key stream.

– Received ciphertext is XORed with the key stream generated to get back the plaintext.

WEP has been broken! Walker (Oct 2000), Borisov et. al. (Jan 2001),

Fluhrer-Mantin -Shamir (Aug 2001).

Unsafe at any key size : Testing reveals WEP encapsulation remains insecure

whether its key length is 1 bit or 1000 or any other size.

WINLAB

Radical take-away: Perhaps we should not try to design a perfectly secure system, but instead add more imperfect solutions to get a better system

Bold Statements:

– Maybe you can’t architect (perfect) security.

– Maybe we should just learn to live with the bad.

– Maybe security and privacy can live together… or maybe not.

Idea: Perhaps we should have lots of little solutions and pile everything on

top of each other and let a smart network figure it out

– These little solutions would be a mix, pulling from crypto-protocols as

well as a variety of other tools

– Physical contexts that might come into play:

Device

Environment

Network

Human

Economy

– Don’t get me wrong, “still need crypto”!!!

[7]

WINLAB

Let’s get physical… let me hear your NIC talk… we know each other mentally…

What are physical contexts that we might be able to use?

– Waveform

– Location

– Timing information (queries, traffic, etc)

– Device:

Type and Chip IDs

Hardware and Software Assurance

– Interfaces and impact on the network

– Context: What you are doing???

– Captcha’s, fingerprint scanners… and other mechanisms that involve the person

– Network structure and transport mechanisms

Code running on the network should be trustworthy

Caching is a physical opportunity to check whether packets/files are trustworthy

Generally, storage is an opportunity

– Work… make things cost something physical, like time or money

– Reputation

[8]

WINLAB

Spatio-temporal access control can be a powerful mechanism for new security functions

What is the conventional way to authenticate the access to a resource?

Identity check

Identity Based Access Control (IBAC)is inconvenient and unnecessary in certain types of scenarios.

Instead, a user’s spatio-temporalcontext is more desirable for basing access control upon.– E.g. A company may restrict its

confidential documents so that they can only be accessed while inside a building during normal business hours.

Spatio-Temporal Access Control (STAC) allows for objects to be accessed only if the accessing entity is in the right place at the right time.

Some advantages of spatio-temporal contexts for security:– Spoofing detection (relativity is your

limit!)

– Remote services can only be accessed if you are in the right place

Challenge: Still requires integration of secure location service

WINLAB

Several future Internet architectures are exploring Name-Address Separation

Separation of names (ID) from

network addresses (NA)

Globally unique name (GUID) for

network attached objects– User name, device ID, content, context, AS name,

and so on

– Multiple domain-specific naming services

Global Name Resolution Service for GUID

NA mappings

Hybrid GUID/NA approach– Both name/address headers in PDU

– “Fast path” when NA is available

– GUID resolution, late binding option

Globally Unique Flat Identifier (GUID)

John’s _laptop_1

Sue’s_mobile_2

Server_1234

Sensor@XYZ

Media File_ABC

Host

Naming

Service

Network

Sensor

Naming

Service

Content

Naming

Service

Global Name Resolution Service

Network address

Net1.local_ID

Net2.local_ID

Context

Naming

Service

Taxis in NB

WINLAB

A future Internet architecture will need name resolution, and this must be able to name abstract entities

The future internet will be mobile– Mobility-centric solutions revolve around name/address splits

– Applications send data to and get data from names

– Names can represent end devices, content, or context

Fast, in-network name resolution is needed to allow flexible name/address separation

– GNRS can be a large-scale, distributed system running over Internet routers

– Updates and queries to a GNRS must not significantly delay messages

Security related to name resolution– Location privacy is a major issue

– Attacks on name resolution can cause large-scale problems

– Update and query messages should be signed by both end user and networks to prevent spoofing attacks

NA1NA2

NA3A B

GNRS Mappings

A -> (NA1, NA2)

B -> (NA3)

WINLAB

The GNRS can be a focal point for security– access control can run through the GNRS based on physical capabilities policies

User should be able to specify:– Which people can see any information about the user’s name

– Which people can see which set of available interfaces mapped to the user’s name

– How frequently people are allowed to receive information about the user’s name (similar to location privacy)

User-initiated cryptographic techniques:– Encrypt specific updates with a group key only available to a target group

Leads to key distribution problems

GNRS-based access control:– Updates contain a policy that specifies who can access what

– Queries contain an authentication token that can be used in conjunction with the policy to supply appropriate information

NameAddress

ListTimestamps Policy

Cryptographic Package

NameAuthentication

Token

Cryptographic Package

Update Query

WINLAB 14

Media

Server

PlanetLab Slice

Storage

Caches

ORBIT

Radio Grid

ORBIT

Gateway

Hop-by-hop File

TransferHop-by-hop

File Transfer Reliable Link

Layer

File sent to multiple

destinations

Media file

(~10MB-GB)

•Wireless Access

•Network

•AP/Gateway

•(CNF “P.O.”)

•Wired Internet with

•Cache & Forward Routers

New transport mechanisms based on hop-by-hop philosophy can provide new security opportunities

Architecture designed to optimize efficient delivery of content to mobile users, but

works well for both wired and wireless device…

Concept based on hop-by-hop transport, storage and caching in the network

New security stems from the physical nature of caching and storing:

Resilience during periods of disconnection

Opportunities to scan content

WINLAB

•Cache ~ 1TB

•Hold~ 1GB

• Buffer ~ 100MB

Lay

ers

of

Sto

rage

Buffer to store content in transit

– We are waiting for the whole file to arrive, use that time wisely…

– Scan for malware/signatures

Hold to store content when router decides not to forward due to disconnection (e.g. DoS), poor path metric, contamination, congestion, etc

Cache for in-network storage, along with redundancy allow for fail-safe mechanisms

•Optimized for content delivery to mobile end users•Scanning and storage allows to ride out disconnection•Never a free lunch… new security threats might arise… “the storage hog”

Using the storage to our advantage, it is possible to scan files as they assemble in the buffer, and engage in policy-driven security actions during migration to hold

WINLAB[16]

Hardware and software security is needed in order to provide a trusted base

Should consider physical attacks on a system such as a radio or a router

– Applications and OS ultimately have a hardware-based root of trust with tamperproof

– Security assumptions made by software may not hold when the hardware can be probed

Research has shown that hardware-based mechanisms can provide a powerful abstraction to implement improved secure network protocols

– Premise: if one can trust the code that generated an output and this code includes input verification, then the output can be trusted

– E.g. A router that is running some of its functions within a TPM… false forwarding cannot happen since the code is what I think it is

Software code attestation can also be used to provide proof that code that is installed is trustworthy

– Similarly, one can use the same mechanisms to prove that I am using certified software (up to a limit!)

WINLAB[17]

Security Via Lower Layer Enforcements: Wireless Security at the Physical Layer

Wireless channels are “open” and hence more susceptible to eavesdropping,

intrusion and spoofing…

Interestingly, wireless channel properties (“RF signatures”) can be exploited for

authentication and to identify attackers

Project on protocols and algorithms for security functions; also experimental

validation

Network A

Noise

Injection

ORBIT Radio Grid

Network

B

Network E

WINLAB[18]

It is possible to use the physical environment to provide a strong source of randomness that can drive other security functions

Entropy pool contamination is a common rootkit exploit that can contaminate other security functions

Use channel reciprocity to build highly correlated data sets

– Probe the channel in each direction

– Estimate channel using recd. probe

Eve receives only uncorrelated information as she is more than l/2 away

Level crossings are used to generate bits

Alice and Bob must exchange msgs over public channel to create identical bits

What if channel is not already authenticated?– Requires additional sophistry to prevent man-in-the-middle attack.

– It is possible using the correlated data collected from received probes.

•Get channel

•estimates

•Key •Key

•Positive excursion

•Negative excursion

WINLAB

•Pseudonym Generation

•Car to Car authentication

•Setup Phase

•Division of Motor Vehicles -

Trusted Authority (TA)

•Electronic License Plate (ELP): ID_BOB

•Certificate: CERT_BOB (certifying PK_BOB)

•Private Key: K_BOB

•Setup parameters for IBE: params

•Authenticate using CERT_BOB

•Verify CERT_BOB.

•Compute pseudo_bob using

timestamp t1 and a secret symmetric

key shared with Trusted Authority :

•Base station id_b1

•pseudo_bob= Enc(ID_BOB || t1) || id_b1|| t1

•secret_pseudo_bob = Extract(pseudo_bob)

• hello || pseudo_alice

•pseudo_alic

e

•pseudo_bob

•Encpseudo_alice(Nonce) || pseudo_bob

•Alice decrypts the encrypted

Nonce

•Nonce

Identity-based cryptography can be used to generate disposable pseudonyms that also support authentication, privacy, and non-repudiation

WINLAB

A Security sub-plane of the management plane would facilitate security services and tie them together

Security management plane

will allow for the

dissemination of

management messages

needed for:

– Control of network

resources

– Reputation

– Security Alarm

– Software Attestation

Management plane is

distinct from routing and

protocol control functions

– Will be architected to use

authenticated management

frames

[20]

Secure Management Agent (SMA)

DATA PLANE

Security Management Plane (SMP)

Data Packet

Security Message Unit

Security

Management Interface

WINLAB

Mobility First is Striving to Build Security Services Centered Around Security Goals

[21]

Integrity:• Assures that network messages were not

modified in transit

• Adversaries may attempt to manipulate

messages in whole or in part

• Adversaries may also seek to disrupt the

“integrity” of a service by delaying,

deleting, reordering, misrouting, etc.

messages through the network

Confidentiality (and Privacy):• Protects against passive

monitoring/eavesdropping

• Adversaries may monitor messages in

whole or in part

• In some cases, the context of a

transaction (e.g. end points and their

locations) are important to keep

private

Non-repudiation:• Prevents an entity from falsely claiming it

did not participate in a service

• Non-repudiation of origin provides proof to

a third party of an originator being involved

• Non-repudiation of reception provides

proof to a third party of a recipient

receiving a service

Access Control:• Ensures that only legitimate network

entitites can establish sessions with

other entities

• Control access to network resources

(e.g. GNRS or network storage)

Authentication:• Entity authentication allows

communicating parties to identify each

other

• Assures the responder of an

association request that the

request came from the correct

entity

• Data origin authentication ensures that all

messages in a session come from same

origin (no hijacking of a session)

WINLAB

Mobility First is Striving to Build Security Services Centered Around Security Goals, pg. 2

• GNRS access control mechanisms can support white-listing/black-listing, as well as multi-grade security policies

• Network capabilities will be integrated into routing to ensure only capable entities can participate

• Public key identifiers provide automatic means for access control

Access Control

• Secure routing protocols will address black hole, replay and misrouting

• Watchdog processes running on network routers will share information on the management plane to detect network wormholes

• Multipath routing and network coding will be explored to ensure resilience in the presence of selective forwarding by corrupted nodes

Service

Integrity

• Secure storage and key management mechanisms will be developed to ensure confidentiality of cached information

• Randomization of paths will be integrated into routing to support location privacy

• Pseudonymous variant of public key addresses will allow for disposable identifiers

Confidentiality/

Privacy