1. Programming Satan’s Computer
Ross Anderson and Roger Needham
Presented by Bert Bruce

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. Messaging Model C B A S S Attacker
Authentication or Certification Server

9. Wide Mouthed Frog Protocol
Uses symmetric encryption
A wants to send to B using a short-lived 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)

10. 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)

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. Protocol Verification Logics
Define logic rule language and apply to a protocol to attempt to find flaws
Rules propagate assumptions/beliefs
Either find flaw or can substantiate beliefs
Several logics tried – results mixed
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

19. 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

20. 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

21. Conclusions / Summary
Programming a computer under malicious control is very difficult
2 possible approaches
Formal methods
Good rules of thumb
Not necessary or sufficient – just useful
Bottom line is be explicit
More explicit ->can be more sure attacker has not intervened
Possibly these principles apply to all programming
Sometimes Murphy is as evil as Satan