Programming Satan’s Computer

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 Attacker S S 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