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