Security and Mobility First: Looking
Back and Looking Forward
The Mobility First Team
Particular thanks to:
Arun Venkataramani (UMass)
Z. Morley Mao (UMich)
Mike Reiter (UNC)
Wade Trappe (Rutgers)
[1]
Introduction: FIA-NP Collaborating Institutions
(LEAD)
D. Raychaudhuri, W. Trappe,
R, Martin, Y. Zhang, I. Seskar
S. Bannerjee
X. Yang
A. Venkataramani, (J. Kurose), P. Shenoy
B. Ramamurthy
Z. Morley Mao
W. Lehr
WINLAB
Talk Roadmap… Where are we going?

MobilityFirst Overview
– Brief (I hope!): motivation and overall design objectives

Dave’s Questions

Rewind: Behind closed doors, what the team was thinking
– Initial security discussions
– Amusing philosophical points of views

MobilityFirst’s Security Design
– Objectives, toolbox and wishlist
– Highlights of what we actually did…
– Half-baked things that are unfinished

Dave’s questions, answered directly…
[3]
WINLAB
Ultra-quick recap: the original design
concepts

Mobility as a basic service (location tracking; fast address
assignment, handoff, network mobiilty)

Robustness with respect to intrinsic properties of wireless
medium (disconnection, varying bandwidth, high error rates)

Support for anticipated mobile/pervasive applications
(requiring features such as location or context awareness)

Enhanced trust models suitable for open wireless channels
and mobile end-users (strong authentication, resistance to
eavesdropping, DDoS and routing attacks)

General usability requirements (such as evolvability, ease and
trustworthiness of management, backwards compatibility,
technology neutrality, economic viability, universal access)
[4]
WINLAB
Concepts led to design goals…

Host and network mobility (G1): End-to-end communication must continue
(i) despite frequent mobility of end-hosts or networks; (ii) despite the absence
of a contemporaneous end-to-end path.

No global root of trust (G2): Correct network behavior must not depend on
a single root of global trust.

Intentional data receipt (G3): An end-host must receive data only if the
transmission is consistent with its receipt policy.

Byzantine robustness (G4): End-to-end communication must continue
despite the compromise of (a small fraction of) routers or end-hosts.

Location-independent content (G5): The network should assist with
content retrieval in addition to enabling host-to-host communication.

Evolvable network services (G6): The architecture should allow for the coexistence or rapid creation of alternate network services.
[5]
WINLAB
And what we got is… The MobilityFirst Future
Internet Architecture
Named devices, content,
and context
Human-readable
name
End-Point mobility
with multi-homing
Strong authentication, privacy
Global Name
11001101011100100…0011
Resolution Service
Public Key Based
Global Identifier (GUID)
Service API with
Routers with Integrated
unicast, multi-homing,
Heterogeneous
Storage & Computing
mcast, anycast, content
Wireless Access
query, etc.
•In-network
•content cache
Storage-aware
Intra-domain
routing
•MobilityFirst Protocol Design Goals:
-
10B+ mobile/wireless devices
Mobility as a basic service
BW variation & disconnection tolerance
Ad-hoc edge networks & network mobility
Multihoming, multipath, multicast
Content & context-aware services
Network
Strong security/trust and privacy model
•Edge-aware
•Inter-domain
•routing
•Hop-by-hop
•file transport
Connectionless Packet Switched Network
with hybrid name/address routing
Mobility &
Disconnected Mode
•Ad-hoc p2p
•mode
WINLAB
MobilityFirst Concepts: Protocol Stack
App 1
Name
Certification
& Assignment
Service
Global Name
Resolution
Service
NCS
App 3
E2E TP1
E2E TP2
E2E TP3
E2E TP4
Optional Compute
Layer
Plug-In A
GUID Service Layer
GSTAR Routing
Link Layer 1
(802.11)
Link Layer 2
(LTE)
Narrow Waist
MF Inter-Domain
Hop-by-Hop Block Transfer
Control Plane
App 4
Socket API
GNRS
MF Routing
Control Protocol
App 2
Link Layer 3
(Ethernet)
IP
Switching
Option
Link Layer 4
(SONET)
Data Plane
WINLAB
Link Layer 5
(etc.)
MobilityFirst Concepts: GUID Service
Example
Service API capabilities:
- send (GUID, options, data)
Options = anycast, mcast, time, ..
- get (content_GUID, options)
Options = nearest, all, ..
Name Certification
Services (NCS)
Register “John Smith22’s devices” with NCS
GUID assigned
GUID lookup
from directory
NA99
MobilityFirst Network
(Data Plane)
Send (GUID = 11011..011, SID=01, data)
GUID <-> NA lookup
GNRS query
Send (GUID = 11011..011, SID=01, NA99, NA32, data)
GNRS update
(after link-layer association)
NA32
GNRS
GUID = 11011..011
Represents network
object with 2 devices
DATA
GUID SID
NAs
Packet sent out by host
WINLAB
Architecture: Name-Address Separation


Separation of names (ID) from
network addresses (NA)
Sue’s_mobile_2
Server_1234
Media File_ABC
Taxis in NB
John’s _laptop_1Sensor@XYZ
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
Host
Naming
Service
Sensor
Naming
Service
Content
Naming
Service
Context
Naming
Service
Globally Unique Flat Identifier (GUID)
Global Name Resolution Service
Network
– 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
BACK AT THE SECURITY
RANCH…
[11]
WINLAB
Dave’s Questions, up front…

What were the security requirements that the project set itself?

How were these requirements developed?

Which aspects of the system were expected to deal with which
security requirements? Core architecture?

Did any features of the new architecture lead to a material
change with respect to the security landscape?

Did the project require or lead to innovations in security
thinking, or the development of new mechanisms?
[12]
WINLAB
The team’s security discussions…
philosophical viewpoints

Looking back, the MF team had some interesting philosophical discussions
about security:
– Is security design like network design?
– Could one “ARCHITECT” security?
– Weren’t all the security exploits a consequence of “devil in the details”
associated with protocols, implementations, etc?

What we all agreed upon was something along the lines:
– Proper network architecture and design does not achieve security, but
creates a toolbox that facilitates the ability to have security
– A bad network design would be one that left out key “tools” that one
needs to then later build (in detail) solutions that address security
problems and are themselves complete.

So: What should we put in the toolbox?

And: Would our toolbox even work?
[13]
WINLAB
The toolbox should have…

No single root of trust:
– We wanted to move away from the single root of trust (c.f. ICANN)
– This gives a decentralized model of trust, e.g. each country manages its own
NCS, or one can shop around for the NCS that meets their needs.

Self-authenticating names
– Public key cryptography provides the ability to prove ownership of the
address if the public key is associated with the address

Apply access control to information that could facilitate attacks

Intentional receipt: recipients should be able to specify what reaches it
– Support intrusion detection and prevention

Disruption tolerance as a means to withstand “broken” or “being damaged”
parts of the network

Understanding the applications that run on top of the network
– Network traffic as a signature for intrusions and bad traffic
[14]
WINLAB
A Wishlist of Mobility First Security
Mechanisms (circa MF Year 1)
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, detect
network anomalies, and enforce policies
• 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
The core security work followed a nice
“hindsight” flow

GUIDs and the GNS:
– The public key as an identifier that can allow for us to rapidly resolve
was paramount to MF
– But is the introduction of a GNS “feasible”? (c.f. Auspice and Caesar)
– What are the security concerns associated with such a new service?

Recipient-driven regulation
– Leverage the GNS to regulate who gets to look GUID-to-NA mappings
(access control at the GNS)
– Issue policies that tell the network “here is how I want you to process
traffic for me”




Could be something like “only certain protocols for me”
On-path and off-path filtering as an allocation problem
Finding signatures for mobile traffic
Securing interdomain routing– attacks exist beyond the cryptographic routing
protocols
[16]
WINLAB
Key Architectural Features: Named
Objects




Globally unique identifiers
(GUID) used to define all
network-attached objects
Key design choice: flat identifier
vs. hierarchical semantic
identifier….
MobilityFirst uses a flat public
key as the GUID
NDN uses domain
name/hierarchical descriptor
Sue’s phone
John’s laptop
Media file M
Context C
Host Naming
Service
Content
Naming
Service
Context
Naming
Service
Globally Unique Flat Identifiers
Global Name Resolution Service
Routers with
integrated storage
and computing
Integrated
storage and
computing
Hop-by-hop
transport
WINLAB
Wait: GUIDs… aren’t they big? Could we ever
use them for real?

How to reduce GUID size: elliptic curve cryptography
– ECC P-256 of FIPS PUB186-3 DSS




Protection for classified information is up to the secret level
Has security strength comparable to RSA with key size of 3072 bits
But one might want to keep crypto choice flexible for future-proofing
Even so, is the whole concept of public keys as a name ever
going to be able to be realized in practical, real router
deployments?
– And what about flat vs. non-flat GUIDs?

The team was aware of this challenge and the team developed fast
and memory-efficient forwarding engine for border routers
(CAESAR)

Key contribution: scalable Bloom filters that support not only
MobilityFirst, but also XIA and other AIP-like architectures
[18]
WINLAB
A quick look at CAESAR…

A forwarding and routing architecture
– For future Internet architectures
– Memory-efficient and high-speed


Scalable and reliable Bloom filters
Two forwarding pipelines
– Performance and correctness
– Multi-match (MM) line

Reliable Bloom Filters)
Common
Path
Primary for vast majority of packets
– Compress states using Bloom filters
– Encode filters in TCAMs for speed

Primary
Path (Scalable and
Backup for very rare cases
Backup Path
– Correct false positives at high speed
– Use a hardware flag


Optimize hash computations
Optimize route updates support
WINLAB
19
CAESAR: Performance comparison
• The total cost is stable for various address lengths
o nmax=4, w = 288
Estimated total cost ($)
16000
Caesar Router
IP Router
12000
8000
4000
0
0
200
400
600
Address length (bit)
800
1000
WINLAB
Overview of Two-Tier Name Resolution: GUIDs,
NCS, GNS
• Network Entity’s Three
Attributes:
- User-level descriptor
- Network-level identifier
- Routable Topological address
• Two Core Services:
- Name Certificate &
Resolution Service (NCRS)
- Global Name Resolution
Service (GNRS)
Obligatory
caveat: At some point
we had a slight divergence in names…
GNS/GNRS, NCS/NCRS… this talk does not address this…
Call it Multi-homing. 
[21]
WINLAB
GNS: Decoupling certification and resolution
Root name service (ICANN,
US. Dept. of Commerce)
2
3
3
1
Managed
DNS
services
Auth.
name
services
4
Name
certification
services
Certificate
search
services
Auspice-like
global name
services
1
4
Local name
services
Local name
services
0
WINLAB
GUID=X, GNS=Auspice
TLD
name
services
Global name system
Name: “Alice’s phone”
Domain name system
Implementation

Geo-distributed key-value store
GUID: {
{IPs: [123.45.67.89, 98.76.54.321]},
{geoloc:[lat, long]},
{TE_prefs: [“prefer WiFi”,…]},
{ACL: {whitelist: […]}},
}

Name certification service
Human-readable name: abhigyan@cs.umass.edu:phone
GUID: 21EC2020-3AEA-4069-A2DD-08002B30309D

msocket user-level socket library with Auspice integration
MSocket socket = new
MSocket(abhigyan@cs.umass.edu:phone);
MServerSocket socket = new MServerSocket(8080);
WINLAB
23
Managed DNS comparison
•Ultra DNS (16 replicas) vs. Auspice 5/10/15 replicas out of 80 locations
240
120
Ultra DNS
(16 replicas)
150
Auspice
(15 replica)
180
•Auspice reduces cost/latency over
•today’s managed DNS
Auspice
(5 replica)
Lookup latency (ms)
210
Auspice
(10 replica)
•One-third replication cost, similar latency
90
60
30
•60% less latency,
•similar cost
0
WINLAB
24
Back to the NCRS & GNRS: We also looked at
the “dirty” security details…
NCRS
Server
NCRS
Server
NCRS
Server
GNRS
Server
1. NCRS
Insert
2. GNRS
Insert
NA1
Jim’s phone
GNRS
Server
GNRS
Server
5. GNRS
3. GNRS
Query
Update
NA2
6. Communication
4. NCRS
Query
NA3
Annie’s car
Jim’s phone
[25]
WINLAB
NCRS Functionalities

Name Translation
– Provide translation between Human
Readable Keywords and Globally Unique
Identifier (GUID)

Certificate Registry
– Analogous to Public Key
Infrastructure (PKI)
– Define certificate format
– Allow self-certifying & certificate assignment
– Certificate registry operations:




Insert (self-certifying) / Certificate request (certificate assignment)
Query
Update
Revoke
[26]
WINLAB
Potential GNRS Attacks

GUID Spoofing Attack:
– A masquerading threat
– A malicious user A claims another user B's GUID and attempts to
associate it with A's own network address by announcing the mapping
(GUIDB, NAA).
– Consequence: denial of service

Stale Mapping Attack:
– A message manipulation attack
– A device moves and issues an update, the malicious GNRS server can
purposely ignore the update and claim it still has the most recent mapping.
Perhaps worse, a GNRS server can selectively choose which (possibly
stale) mapping to give out during queries.
– Consequence: denial of service
[27]
WINLAB
Potential GNRS Attacks

False Announcement Attack:
– A information modification attack
– User A, which is in network NAA, claims its GUIDA binds to a different
network address, (GUIDA, NAB).
– Consequence: illegitimate resource consumption

Collusion Attack:
– A information modification attack
– A malicious user, its network and the location where the mapping is stored
collude with each other to allow a fake mapping involving a false network
address to pass the verification and become stored in the storage location.
– Consequence: denial of service
[28]
WINLAB
And we got stuff like: Securing GNRS Update
Main network components: updater, local router, border gateway
More
where
that
camestorage
from…
router,
DHCP
server,
mapping
location.
But let’s save that for the student talk tomorrow…
DHCP
Server D
3. G to D: {GUIDG, [Ng, GUIDA,
(GUIDA, NA1, TA, EA)A-1]D}
NA2
4. D to G: {Ng+1, (GUIDA,
NA1, TA’, EA’)D-1}G
5. G to L:
{Nl+1}G-1
NA1
6. L to A:
{Na+1}L-1
A
Local
Router L
Border
Gateway
Router G
8. X to G: {Ng’+1}X-1
X
7. G to X:
{GUIDG, { [GUIDA, Ng’, (GUIDA, NA1, TA,
EA)A-1,G-1 ]G-1}x}
2. L to G:
{GUIDL, [Nl, GUIDA, GUIDG, (GUIDA, NA1, TA, EA)A-1]L-1 }G
1. A to L:
{GUIDA, [Na, GUIDL, (GUIDA, NA1, TA, EA)A-1 ]L}
[29]
WINLAB
Revisiting recipient control: Controlling Access
to GNRS Information

User (the recipient) should be able to specify:
– Which people can see what 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
Further problems and why “Access Control in
GNRS” is good…

Problem
– No protection for the mapping from being queried by illegitimate
users.

Consequences
– Information/privacy leakage.
– Attacks, e.g. DoS attack.
– Track users’ behavior, etc.

Solution
– Integrating access control to the GNRS.

Benefits
– Protect mapping information from unauthorized access.
– Support advanced services and fine-grained functionalities.
[31]
WINLAB
Overview of Access Control in GNRS

Access control language
– eXtensible Access Control Markup Language (XACML)
– Can handle basic GNRS access control, identity-based access control
(IBAC) and attribute-based access control (ABAC)

Policy format
– Basic format: (GUIDB,TB, EB )A-1
– Whitelist/backlist: {(W,GUID1,T1, E1 ),(B,GUID2 ,T2, E2 ), }A-1
[32]
WINLAB
Spatio-temporal Access Control in GNRS

General Spatio-temporal access control (STAC)
– Target

Grant the mapping based on spatio-temporal (ST) characteristics.
– Challenge



A malicious user may lie about its location.
No guarantee for the correctness of the ST information.
Little support for the security of submission process
– What our team managed to do:


Incorporate ST verification to ensure the correctness of ST
information.
Adopt various security mechanisms to secure the query process.
[33]
WINLAB
Spatio-temporal Access Control in GNRS

Spatio-temporal access control with state transitions
– Definition of state


Being at a specific location in a specific time interval.
Is represented by a location L and time interval (T, E) as <L,T,E>.
– Target: A stateful form of access control

Accessibility to the mapping depends on not only the current state,
but also the previous state.
– Challenge

Scalability & efficiency issue: a large burden for distributed
servers to maintain users’ state records in a large scale mobile
network.
– Solution

Introduce a token-based approach to handle the state verification
process.
[34]
WINLAB
Back to intentional receipt and NIDS/NIPS

AC at the GNRS does not completely remove adversaries from knowing
network addresses

“Intentional receipt” (versus receiver control) was one of the goals that was
set out at the beginning of the project:
– Each end-user device or neighbor network attached to network X ought
to be able to express policies (that X should enforce) about the traffic that
X passes along to it.

These policies could be rich (e.g., content-based, not just address-based).

With potentially every end-user device expressing such policies, the real
challenge for network X is how to scalably enforce those policies.

The MF team addressed this problem
– Solution also addresses fundamental challenge in network intrusion prevention
systems (NIPS)
– Validated through an SDN implementation
[35]
WINLAB
Perpetual Scaling Challenge
• Traffic increase  More packets to process
• User applications changing  More functions/modules
• Attacks evolving  Larger set of “rules” to apply
WINLAB
36
SNIPS System Overview
High-level goals:
Latency, Unwanted
Link/Node Load
Administrator/Recipients announce
Policies to SNIPS
Decide local processing
and offloading
SNIPS Network Controller
responsibilities
N1
N2
N3
D1
WINLAB
37
SNIPS Controller Design
High-level goals:
Latency, Unwanted
Link/Node Load
Traffic
Classes
NIPS
Resource Use
Decide local processing
and offloading
responsibilities
NIPS, DC
Hardware
Topology
& Routing
Network-Wide
Optimization
N1
Class c = HTTP, N1  N3
c.in= N1; c.out = N3
c.Path = <N1, N2, N3>
N2
N3
D1
WINLAB
38
SNIPS Offers Better Load Balancing
WINLAB
39
Complementing the work on SNIPS is the
need to be able to characterize traffic

Mobile traffic is difficult to characterize
– Most mobile applications do not use specific protocols or IP ports
with distinctive features
– This makes it hard for “the local network” (e.g. enterprises and
service providers) to regulate the traffic that flows over their
network

In order to support in-network removal of traffic, the team
developed a solution (FLOWR) that identifies apps via traffic
analysis
– FLOWR uses a customized supervised learning approach that can
grow its collection of app signatures
[40]
WINLAB
FLOWR: Basic Principles
1. What to identify?
Bi-directional flows
2. How to identify flows?
Signature matching
KV tokenization
3. How to extract signatures?
HTTP metadata can be indicative to app identities
4. How to construct a knowledge base?flow regression
Flow signatures from the same app often co-occur
5. How to initialize the knowledge base? a* services
App IDs are always embedded in ad and analytics
•http://api.airpush.com/v2/api.php?...&packageName=zz.rings.rww2&...
41
WINLAB
Key-value (KV) examples
admob.com
&preqs=0&u_sd=1&slotname=a14d9cfab0d6002&u_w=320&ms
id=tls.game.fiar&cap=m%2Ca&js=afma-sdk-4.1.1&isu=F139F4FD31A7049ECD
A0C320F96B92CB&format=320x50_mb&net=ed&app_name=9.android.tls.game.fiar&
hl=en&u_h=480&u_audio=1&u_so=p&output=html
scorecardresearch.com
&c1=19&c4=Total%20Beauty&c10=android&c12=5d
30b552b3874617ed84ca2de98c3ff1-a&ns_ap_device=generic&ns_ap_as=13384
40029585&ns_type=View&ns_ts=1338440029626&ns_m2=yes&c2=6035713&name=s
tart&c3=Start&ns_ap_ver=1.5.2&ns_ap_res=480x800
App ID: msid=tls.game.fiar, c12=5d30b552b3874617ed84ca2de98c3ff1-a
Developer ID: c2=6035713
Device ID: isu=F139F4FD31A7049ECDA0C320F96B92CB
General: js=afma-sdk-4.1.1, format=320x50_mb, hl=en, ns_ap_res=480x800
Random: ns_ts=1338440029626, ns_ap_as=1338440029585
42
WINLAB
KV tokenization
•…
•http://airpush.com/?
&sdkapid=67526&zipcode=48109
•…
•http://airpush.com/?
sdkapid=67526&zipcode=48109
•airpush.com:sdkapid=67526
•airpush.com:zipcode=48109
•airpush.com:sdkapid=67526
• ->com.rovio.angrybirds (TP: 99%)
•com.rovio.angrybirds (TP:
99%)
KV tokenization extract KVs from flows into signatures
43
WINLAB
Full picture of FLOWR system
Knowledge base initialized using a* services
with minimal manual effort (seed knowledge)
44
WINLAB
FLOWR: Some results…
t90,95,99: uniquely identify with confidence 90,95,99%
n5: narrow down to 5 candidates with confidence 99%
45
WINLAB
Routing Security: Advancing the science of
secure interdomain routing

The team also explored the problem of secure routing from a
new perspective where the adversary was corrupt AS’s with
Byzantine behavior

BGP, even with S-BGP mechanisms, vulnerable to serious
protocol manipulation attacks

The MF team’s contributions
– Formalized two fundamental correctness properties and show
there are feasible attacks that violate them
– Validated attacks with commodity routers
– Quantified attack vulnerability in the Internet
– Propose RCI-based approach to provably satisfy properties
46
WINLAB
BGP Control Plane Attacks, a solution, but
not enough!

BGP control plane attacks
– Prefix hijack: pretend to own a
prefix
– Path spoofing: announce a
forbidden path

Solution: S-BGP
– Ensures existence
– Ensures authentication

S-BGP (and follow-ons) ensure
verifiability of routing information using
cryptographic techniques

Our main contribution
– Manipulate the complex BGP
protocol to violate two of its most
fundamental goals (even with S-BGP
mechanisms)
AS 2
AS 1
BGP, even with S-BGP mechanisms,
vulnerable to serious protocol manipulation
attacks
Even without breaking any secure protocols,
attacks can permanently cut a connection and
permanently force a victim AS to select a less
preferred path.
WINLAB
Advancement in Security Objectives:
Desired Correctness Properties

Property 1: Eventual Reachability (ER)
Existence of a good path should ensure eventual reachability

Property 2: Policy Prevalence (PP)
Existence of multiple good paths should ensure selection of
the most preferred path
WINLAB
The Soufflé is still in the oven for many
things…

Robust multipath traffic allocation using portfolio theory

Integrating trust assessment into MF: router assessment services, how to
incentivize rating, how does one allow for trust to regrow after losing it,
integrating trust with inter/intra-domain routing

Designing a context-based communication service in a privacy-preserving
manner

Robust network protocol designs to prevent abuses and protocol
manipulation attacks from network services.

Network protocol designs to eliminate side channels for protecting user
privacy and eliminating data injection attacks

Integrating “security as a network service” in order to support IoT security

Storage verification: if in-network caching is being advertised, how do you
trust what you are being told?
[49]
WINLAB
And then there was stuff that just didn’t pan
out… aka, the graveyard of failed research…


Example: It was thought that the use of public key naming addressing
schemes might facilitate access control through pairing-based (ID)
cryptosystems
Using such ID-crypto in public key addressing allows for flexible access
control to data:
– Data is encrypted at the source using the (single) public key that is derived by the
logical conjunction and disjunction of destinations’ identities (public keys)
 Example: Packet payloads can be encrypted so that either Darleen or
Victor can access, but only the Darleen who is at NSF and in DC and
in the USA, or the Victor who is at NSF and also has a Comcast
account

Challenge 1: Does not obviate the need of a structure akin to certificate
authorities (must maintain pairing)

Challenge 2: Does not easily support integration with necessary
timestamping for integrating within GNRS

Challenge 3: Combinatorial operations in crypto domain were not arbitrary
[50]
WINLAB
Dave’s Questions, revisited…

Looking back at Dave’s Questions:
– What were the security requirements that the project set itself?
– How were these requirements developed?
– Which aspects of the system were expected to deal with which security
requirements? Core architecture?
– Did any features of the new architecture lead to a material change with respect to
the security landscape?
– Did the project require or lead to innovations in security thinking, or the
development of new mechanisms?

Our requirements arose out of “design goals” and “philosophy”

We then found places to apply these goals, e.g. intended receipt/recipient
control

We worried about whether our security ideas might be practically realizable
(e.g. CAESAR)

Innovation to secure routing thinking: new correctness metrics that exist
outside the cryptographic framework
[51]
WINLAB