Programming Satan’s Computer
Download
Report
Transcript Programming Satan’s Computer
Programming Satan’s Computer
Ross Anderson and Roger Needham
Presented by Bert Bruce
Satan’s Computer
Computer under the control of an
inimical force
Can alter or intercept data
Need to be able to detect when this
happens
Overview
Use of cryptography
Doesn’t mean there is security
Doesn’t mean data is protected
The key to security is overall system
and protocol design
Examples
Prepaid Smartcard
Encoded the current value
Didn’t encode the rate
Attacker can change the rate to be very
low
Then attacker gets much more for his
money
Examples
ATM Card
Magnet stripe holds Account # and PIN
(like name and password)
Account # is embossed on card, so no
point in encoding that
PIN is encoded
ATM machine reads Account #
To verify, user must enter PIN that
matches the one on the card
Examples
ATM Card (cont.)
ATM doesn’t have table matching
Account # and PIN
Attacker can alter the Account # on the
magnetic stripe and leave PIN alone
Attacker
doesn’t need to know encryption
algorithm
ATM machine accepts attackers valid PIN
but uses altered Account #
Correct Method: Account # and PIN
should be encrypted together
Examples
Hacking Pay-per-view TV
Hardware includes
Authentication
(Smartcard)
Microcontroller
Video
decoder
System can be hacked by
Replacing
any one of these
Interposing attackers processor into one of
the communications channels between these
Messaging Model
A
C
B
Attacker
S
S
Authentication or Certification Server
Wide Mouthed Frog Protocol
Uses symmetric encryption
A wants to send to B using a shortlived encryption key
S shares permanent keys with A and
B: KAS and KBS
A sends a timestamp, the name of
the recipient (B) and the short-lived
key to S (encrypted with KAS)
S sends to B its own timestamp, the
sender (A) and the key from A
(encrypted with KBS)
Wide Mouthed Frog Protocol
Now A and B have the temporary key
and can exchange messages
After they are done, key should time
out
But attacker can keep the key alive
with the hope of stealing either A or
B’s hardware (e.g. Smartcard)
Wide Mouthed Frog Protocol
Attack method:
C sends original message from S to B
back to S
This
looks to S like a request to set up key
with A, so S sets new timestamp
C then intercepts message from S to A
and sends it back to S, etc.
This
keeps the temporary alive for an
indefinite time
If C can get A or B’s cards, can then
decrypt using the key
Challenge-Response Protocols
Use shared key
Protocol:
A tells B he wants to converse
B sends random number back to A
A encrypts and returns it
B decrypts – if match, then B knows it
came from A
Challenge-Response Protocol
Woo and Lam Variant
A and B share keys with S, not each
other
B sends A’s name and encrypted
message to S
S decrypts A’s message and re-encrypts
for B and sends it to B
But if C starts communication with B at
same time, can replace message from S
to B regarding A with its own message
Then
B thinks C is A
Challenge-Response Protocol
Solution is to include encrypted
names in the messages as well
Then C can’t pretend to be A
Moral: if identity of principal is
essential to meaning of message,
include the identity in the message
Don’t assume identity just because of
from where it appears to come
Digital Signatures
Based on symmetric Public Key Encryption
Signer encrypts using private key
Anyone can decrypt using the signer’s
public key
A signs message w/ private key and
encrypts with B’s public key
B decrypts message w/ private key and
checks signature w/ A’s public key
Redundant info in message can insure C
hasn’t substituted his own message
Other Public Key Issues
C can post a public key and claim it is
from A
This means security is required in key
management
But even then, if names not included
in messages, C can masquerade as
someone else
Middle Person Attack
C pretends to be someone else by passing
encrypted messages unchanged
C passes message to B as if from A
B responds to A. C can’t decode, he just passes
to A
A responds to C thinking message is from C
C decodes and re-encodes response to B with
B’s public key
Again needs names in messages to prevent
Protocol Verification Logics
Define logic rule language and apply to a
protocol to attempt to find flaws
Several logics tried – results mixed
Rules propagate assumptions/beliefs
Either find flaw or can substantiate beliefs
One issue – do rules include “freshness”
Public key methods are hard to formalize
Most gain seems to come from
formalization of protocol rather than
automation
Some Robustness Principles
Be explicit – goals, assumptions,
purpose
Put identity in message if it essential
to meaning of message
A signature attached to an encrypted
message means nothing
Signer may know nothing of contents
Don’t confuse decryption with
signature – 1st can be faked, 2nd can’t
Uniquely identify protocol; runs –
don’t allow replays
Explicitness Principle
A cryptographic protocol should make
any necessary naming, typing and
freshness information explicit in its
messages; designers must also be
explicit about their starting
assumptions and goals as well as any
algorithm properties which could be
used in an attack
KISS doesn’t always work if simplicity
removes vital information
Conclusions / Summary
Programming a computer under malicious
control is very difficult
2 possible approaches
Formal methods
Good rules of thumb
Bottom line is be explicit
Not necessary or sufficient – just useful
More explicit ->can be more sure attacker has
not intervened
Possibly these principles apply to all
programming
Sometimes Murphy is as evil as Satan