Mini Symposium on
Information Security
Northeastern University College of Computer and
Information Science
November 9, 2004
Whitfield
Diffie -The Prospects for Secure Computing
Elisa
Bertino - Trust Negotiation Systems - Concepts and Issues
Insup Lee – Bridging the gap between
specification and implementation
Guevara
Noubir – Scalable Robust and
Secure Wireless Networks
Burt Kaliski - Cryptography and Data
Security - Long Term Challenges
Information security is 100 years old
Radio changed everything
Before radio – central command of navy had no clue where his fleet was
After: A single day, soon down to hours or minutes
BUT: other people can listen in – no control over the channel
Primary information security problem
Radio uses cipher codes
Not terribly well suited to human use – to easy for error propogation
In WWI – the Enigma design of electro-mechanical encryption
Need table-lookup ability
WWII – had 10-character/second telegraph
WWII – 1st secure phone – Sig Sally
200bit/second vocoder
Uses one-time pad
long-playing records of random bits
To replicate this speed, need electronic systems w/ shift registers: can’t use electomechanical
70s – still character lookup
Public Key – move from multiplication to exponentiation
Crown jewel of crypto – Advanced Encryption Standard (AES)
Would have been incomprehensible 10 years ago
Supports long key lengths, even at lowest strength
Adopted by the US gov’t, and in 2003 for all levels of classified data
Cost considerations imply that it likely will come into use
Crypto Rump Session – found collisions in SHA-0
Too much WWII mentality for new algorithms
People are too afraid to their encryption algorithm being broken
Too many startups based on new systems
“I think we’re in pretty good shape”
Paradigm shift in computer security in the 70s
With the advent of multiple user systems, have new question of seperation inside the system
Off-the-shelf systems spread through the research world
Not trusted by the standard Intelligence security community
Nightmare scenario: a compiler is taking notes on a classified program that is compiling
à Confinement
Run programs in confined environments so that they can’t hurt you
70s-80s – doesn’t leak your top secrets
Today – “we’re happy if it doesn’t take over your machine”
Rules: read only what you’re supposed to read, can’t downgrade clearances
Problem: covert channels inside system
I.e. can signal other programs by trying get into the run queue
30 years on – Best System is Sun’s Trusted Solaris
BUT – still worse than the original specification
Why will we do better in the next decade than we have in the past 3?
1) Cryptography
We know more about cryptography now, more widely implemented
More fundamental than network traffic: can use it to define and verify system states
Use it to secure, authenticate system state
2)Hardware
Guard the keys on the hardware level
Prevents other software from undermining key system
No way to get the key if the hardware doesn’t have the command to get key
3) Trusted computing platforms
Ask whether I am running what I think I’m running
Simplest: boot off original media (CD from factory)
BUT – nflexible, can’t patch
More flexible – boot off a boot server
BUT – need to make sure that you’re getting the right image
Have to check sigs on the
BUT – only use one OS
Most flexible – attestation set
Credible claims that you are running what you actually are
4) Networking
Another least-appreciated computer advances – Client-server computing
Have a sensitive process: put it on a computer by itself
Sensitive information is isolated, just focus on good gate-keeper
Want to flexibly allocate processes to processors
Hardware-enforced domains that allocate resources, keep processes isolated
Helps (but doesn’t solve) covert channel
Grid computing – computers as networks
Opposed to Von Neuman machine, which uses flexibility between information and instructions
Source
of stack execution exploit (Buffer overflow)
Grid – every process uses network I/O
Can now use network policy
5) Language advances
1st generation talked about operating systems
Don’t need to secure all instructions
Nature of information is to be inscrutable – i.e. halting problem
BUT – can build decidability into language
i.e. Architecture only allows things to run for a certain time limit à things will always halt
Analog – statement about investigability of code
E.g. We don’t know that you are bad, but you were unaccountable for 3 years, so you could be a spy
Solution: only run code that you can understand and inspect
Java is the camel’s nose
Java code will behave nicely
BUT – need to inspect that the binary is from a compiled java program
Inspect
the binary to prove that it came from a java program – Is this possible???
Proof-carrying code – executables come with provable attestations that they came from good code
Improvements / Predictions
Web services are going to work
Caveat – some disagree
Now – know where my programs are running
One my desk
At ebay, amazon, etc
Algorithm selling
Suppose Fast Fourier Transforms were proprietary – only run by Princeton
We have the possibility of going into business to run algorithms inhouse
People can outsource processing
Utility computing
Complements the algorithm startup
BUT – how do you manage trust flow?
It will have to look like the sub-contracting procedure
Building security into contracts
Can we learn anything from contract theory?
Need enforcement mechanisms
Have some real-world examples: secure copying center
Negotiation and configuration control
Q: Speaker yesterday brought up question of how you now the web connection is valid. What about algorithm? How do you guarantee trustworthiness?
A: Need good interface (why is the browser resizable), need authenticaion (SSL) but should use bilateral authentication – scalability
BUT – he acknowledges that SSL only checks if someone paid verisign
Need to start with a trusted client
I.e. trusted solaris has a part of the screen that no processor can get rid of
Problem of authenticating processes is practical, not principle of CS
Q: How do you control the life-cycle of a document?
A: Problem in the large and the small
Large: why are some secrets kept for decades, but not others?
Interesting top-level secrets leak faster than boring confidential
STILL: why don’t secrets leak faster?
Same social network that spreads can also slow them
Need a political science/ sociology study of secrets
Small: Can’t clean up after ourselves – very little disk-scrubbing
C: Browsers are buggy, frustrating
A: Need a keying infrastructure
Not an adequate commercial motivation – high startup cost
Many definitions of trust
Kini & Choobineh – belief based on opinions of systems
Human element
Gambetta – quantifiable probability that agent will perform action
Independent of monitoring
Gradison & Sloman
Firm belief in the compentency to act dependably, securely and reliably
Trust relations
Specific for given type of transaction
A trusts B for X
Measurability is desirable
At least relative valuation: A trusts B more than C
Directed
A trusts B is not the same as B trusts A
Things that can help with trust management
Identity services
Authentication services: access to resources
Delegation, fine-grained access,
Anonymity services – need some accountability too
Trust rating and recommendation
3rd party notarization
Auditable logs, secure storage, guaranteed message delivery
BUT – information flows so variably, that you have to control all the flows, or cannot control any of it.
Trust negotiation model
Goal: establish trust between parties in order to exchange sensitive information and services
Mutual exchange of credentials
Disclosure policies are ad hoc,
Alice wants to see credential from ecommerce site about BBB before she releases her credentials
Language requirements
Well-defined semantics
Monotonicity
– not sure how this matters…
Credential combination
Authentication
Constraints on property values (properties of attributes)
Privacy issues if anyone can prove predicate
Sensitive
policies – not sure why I don’t want to spread the policy? Is this security through obscurity?
System requirements
Credential ownership
Credential validity
…
Examples of systems
Keynote – Blaze and Faigenbaum
TrustBuilder
Trust-X – Bertino et al.
Trust-X
XML framework
Sequential execution of phases
Introductory – no critical information exchanged
Policy exchange
Credential exchange
Done in an order specified by policies
Key phase: policy evaluation - bilateral
Privacy issues
Include P3P as part of the policy
Often demand more credentials than necessary
Problem: possibility of deadlock where each side demands to see other credential first
Alice wants to see pharmacy’s cert before releasing
BUT – pharma will only disclose it to known patients à why?
Can use
privacy-enhanced credentials to avoid deadlock – follow up on how this works
Paranoid ratings:
Standard
Suspicious – always ask the other party to prove that they have credential
How do you prove that you have cert without
revealing sensitive aspects of cert
Strongly suspicious – demand actual credential
Trusting – speed thngs up
Need to think about relative value of given pieces of information
(Italian & University) < (American & University)
Private concept groups – assumptions about what the other party knows
Q: Transitivity in trust management?
A: Could be very useful, but not the primary focus.
Problem –
Scalability wrt. Size and complexity
SW has more details
Solutions
Model-based code generation
Run-time verification
Model checking is formal, but doesn’t scale well
Funtime verification
Use a verifier running alongside the program to see if the program has run properly
Can use feedback to program to correct itself
MaC & runtime verification
… [took care of some administrative work during much of this talk]
Can use this for intrustion detection
Make sure that the code has not been tampered with
Many benefits of flexible, reconfigurable networks
Ubiquitous computing
Disasters – need to rebuild network
Safety services
Need better technology for this – no integration, no QoS, no seamless adaptivity,
Characteristics of wireless networks
Limited radio spectrum
Shared medium – collisions
Limited energy at nodes, limited computation
Limited storage
Dynamic topology with unreliable connectivity
Need to enforce fairness
BUT – networks are very flexible, nodes can adapt
Attacks
Multilayer DoS attacks
Physical layer
Can partition network, or force packets to chosen paths
Just needs to cause a few bits to be lost to ruin whole packet
Counter: spread spectrum, directional antennas
Higher level: crypto interleavers (cover traffic) jam-free or mobile
MAC layer – target control traffic and mechanisms
Backoff allows attacket to spend less energy
Network – injection, or disruption of routing info
Inject wrong routing data: disruption or resource consumption
Black hole, routing loop
Blackmailing – ruin a routers reputation
Transportation – exploit weakness in congestion control
Secure multi-casting
Ad Hoc vs. wired multicast
Unreliable links, Higher packet loss
Cost as a function of hops
Accumulative relaying
Subset of a general relay problem
Wave path – use a heuristic to find a lower energy boundary of transmission
`
Two kinds of solutions: apply current knowledge to alleviate problems, or discover new knowledge that overcomes them
Looking ahead 30 years
1)Algorithms are robust for 30+ years for known attack on classical computers with sufficient keys
BUT: Quantum computers would break number theory-based public key crypto, halve effective private key size
Point: with few exceptions, no algorithms are proven secure unconditionally
Easy Solutions (with current tech)
Employ multiple different algorithms
I.e. sign something twice
Deploy secret-key crypto long term
Use Merkle hash signatures – not number theory based
BUT – could still be vulnerable to specific attacks
Include a link with quantum cryptography
Better solutions
Develop alternative algorithms for PK’s
Need a long testing process
Provable resistance to attacks, either new algs or existing ones
Quantum crypto that does not require photon transmission
2)No data is safe in the long run
Usability competes with security
Side channel analysis can expose keys
i.e. number of multiplies in a decryption can reveal key
Availability requirements encourage multiple copies of data
Storage of keys
Easy solutions
Build implementations that address side-channel attacks
Employ architectures with implicit keys
Secret splitting – n shares with k required to reconstruct
Distributed cryptography – k shares are never reconstituted, but used in series
“Heal” the effect of compromises
Pro-active – assume that they will be compromised, shares are periodically refreshed
Limits future use of breakdown
Can do it simply from a mathematical perspective – split a 0 to maintain the sum
Forward – keys are updated periodically such that past keys cannot be computed from current ones
Put bounds on compromise – maintains validity of past signatures
Better
Better algorithms
Develop new, practical data protection techniques
Invent something physics-based
3) Future networks may be less secure
Mobile or ad hoc creates more attack opportunities
Router table issues
Selfish nodes
Need an architecture of implicit data built on a foundation of provable algorithms
From gigabit security to terabit and beyond
Q: What about policy issues?
A: Attention to security – that it’s part of safety
Need R&D, need to think about quantum computing
Will the market sustain growth? What is the marginal benefit of a partial quantum computer?
ROI
C: Quantum encryption in RF is possible, but the energy is less than ambient temperature
These notes were transcribed by Allan Friedman at the conference. They represent only a fraction of the papers presented, since the conference consisted of several parallel sessions. It is possible that I may have misunderstood some of these presentations, or missed an important point. All italic comments are personal notes, and should not be attributed to the speaker. It goes without saying that curious readers should read the actual papers; those interested should contact the authors.