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 C B A S S Attacker Authentication or Certification Server

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)

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

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