Alice and Bob get Physical:
Introducing Physical Contexts into
Security for the Future Internet
Wade Trappe
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???
[1]
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 codesigning 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):
–
–
–
–

Consider CMEA:
–
–
–
–
–
–

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
CMEA is its own inverse (every key is a “weak key”)
CMEA encrypts short blocks, but cellular telephony did not employ CFB, or random IVs
codebook 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 ~2 32 complexity; 2byte 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-temporal
context is more desirable for basing
access control upon.

 Some advantages of spatio-temporal
– E.g. A company may restrict its
contexts for security:
confidential documents so that they can
only be accessed while inside a building
– Spoofing detection (relativity is your
during normal business hours.
limit!)
– Remote services can only be
 Spatio-Temporal Access Control
accessed if you are in the right place
(STAC) allows for objects to be
accessed only if the accessing entity is
in the right place at the right time.

Challenge: Still requires integration
of secure location service
WINLAB
Several future Internet architectures are exploring NameAddress Separation


Separation of names (ID) from
network addresses (NA)
Server_1234
Sue’s_mobile_2
Media File_ABC Taxis
Globally unique name (GUID) for
network attached objects
John’s _laptop_1
– User name, device ID, content, context, AS name,
and so on
– Multiple domain-specific naming services


Host
Naming
Service
Sensor@XYZ
Sensor
Naming
Service
Content
Naming
Service
Context
Naming
Service
Globally Unique Flat Identifier (GUID)
Global Name Resolution Service for GUID
 NA mappings
Global Name Resolution Service
Network
Hybrid GUID/NA approach
– Both name/address headers in PDU
– “Fast path” when NA is available
– GUID resolution, late binding option
Network address
Net1.local_ID
Net2.local_ID
WINLAB
in N
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
GNRS Mappings
A -> (NA1, NA2)
B -> (NA3)
NA2
NA1
NA3
A
B
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
Update
Query
Cryptographic Package
Name
Address
List
Timestamps
Cryptographic Package
Policy
Name
Authentication
Token
WINLAB
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
ORBIT
•Wireless
Access
•Network
Radio Grid
•AP/Gateway
ORBIT
Gateway
•(CNF “P.O.”)
Hop-by-hop
File Transfer
Reliable Link
Layer
Hop-by-hop File
Transfer
Media file
(~10MB-GB)
Storage
Caches
•Wired
Internet
with
PlanetLab
Slice
•Cache & Forward Routers
Media
Server
File sent to multiple
destinations
WINLAB
14
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

Buffer to store content in
transit
–
• Buffer ~ 100MB
–
Layers of
Storage

•Hold~ 1GB
•Cache ~ 1TB

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 failsafe 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”
WINLAB
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
–
–

Research has shown that hardware-based
mechanisms can provide a powerful abstraction
to implement improved secure network
protocols
–
–

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
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!)
[16]
WINLAB
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
ORBIT Radio Grid
Network A
Network
B
Noise
Injection
Network E
[17]
WINLAB
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.
•Positive excursion
•Get channel
•estimates
•Negative excursion
[18]
•Key
WINLAB
•Key
Identity-based cryptography can be used to generate disposable
pseudonyms that also support authentication, privacy, and nonrepudiation
•Pseudonym Generation
•Setup Phase
•Base station id_b1
•Division of Motor Vehicles Trusted Authority (TA)
•Authenticate using CERT_BOB
•Verify CERT_BOB.
•Compute pseudo_bob using
timestamp t1 and a secret symmetric
key shared with Trusted Authority :
•pseudo_bob= Enc(ID_BOB || t1) || id_b1|| t1
•secret_pseudo_bob = Extract(pseudo_bob)
•Electronic License Plate (ELP): ID_BOB
•Certificate: CERT_BOB (certifying PK_BOB)
•Private Key: K_BOB
•Setup parameters for IBE: params
•Car to Car authentication
•pseudo_alic
e
•pseudo_bob
• hello || pseudo_alice
•Encpseudo_alice(Nonce) || pseudo_bob
•Alice decrypts the encrypted
Nonce
•Nonce
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
Secure Management Agent (SMA)
Security Message Unit
Security
Management Interface
Security Management Plane (SMP)
Data Packet
DATA PLANE
– Will be architected to use
authenticated management
frames
[20]
WINLAB
Mobility First is Striving to Build Security Services
Centered Around Security Goals
Authentication:
• Ensures that only legitimate network
entitites can establish sessions with
other entities
• Control access to network resources
(e.g. GNRS or network storage)
• 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)
Confidentiality (and Privacy):
Integrity:
Access Control:
• 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
[21]
• 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
WINLAB
Mobility First is Striving to Build Security Services
Centered Around Security Goals, pg. 2
Access Control
• 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
Service
Integrity
• 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
Confidentiality/
Privacy
• 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
WINLAB