Document Sample
api-seattle Powered By Docstoc
					Satan‟s Computer -
    Ross Anderson

     December 2005
                Talk Structure
• Programming Satan‟s Computer
• Discovering Security APIs: ATM security
   –   ATM Security Basics
   –   Early attacks on HSMs
   –   Finding Faults in Type Systems
   –   Problems with DES
   –   Information Leakage Attacks
• The Future of Security APIs : Trusted Computing
   – Digital Battlefields
   – Getting formal
• Conclusions
• Security protocols used for 25 years to
  authenticate users, authorise transactions
• E.g. „wide-mouthed frog‟ protocol – Alice and
  Bob each share a key with Sam, and use him as a
  key-translation service
    A -> S: {TA, B, KAB}KAS
  S -> B: {TS, A, KAB}KBS
• Errors kept being found in protocols, often years
  after the fact!
             Background (2)
• Example in banking – offline PIN verification as
  used by NatWest and others, until early 1990s:
   A/c no, {PIN}KATM, Limit, Exp
• First attack – clone the cards
• Second attack – cut and splice your encrypted PIN
  value with other people‟s account numbers
• Led UK banks to move to online-only processing
  from about 1993
          Satan’s Computer
• We usually assume „computer good, program
  probably bad‟
• Yet a network under an adversary‟s control seems
  the most hostile computer there is
• Unlike „Murphy‟s computer‟, the adversary causes
  the worst possible things to go wrong – hence
  „Satan‟s computer‟
• What can we do? Well, 25 years of protocol
  analysis work have left us with many useful rules
  of thumb, and papers on applying formal methods
Hardware Security Modules
            What is a Security API ?
• An API that allows users to work with sensitive
  data and keys, and uses cryptography to enforce
  a policy on the usage of data

                                                   I/O Devs
  Security Module                   Host
                                 PC or Mainframe
   PCI Card or Separate Module

        Security API
• Enforcing access policies to sensitive information
   Example: granting signing permission at a CA
• Protecting critically sensitive data
   Example: PIN generation keys at banks
• Protecting data in hostile environments
   Example: making it harder for operators to tamper with token
     vending machines (electricity, national lottery etc…)
• Coping with high crypto throughput requirements
   Example: SSL acceleration for web servers

   … the first three are all about dishonest insiders, the fourth often
    partly so
   Hardware Security Modules
• An instantiation of a security API
• Often physically tamper-resistant
  (epoxy potting, temperature & x-ray sensors)
• May have hardware crypto acceleration
  (not so important with speed of modern PC)
• May have special „trusted‟ peripherals
  (key switches, smartcard readers, key pads)

(referred to as HSMs subsequently)
       ATM Network Security
• ATM security was the “killer app” that brought
  cryptography into the commercial mainstream
• Concrete security policy for APIs:
  “Only the customer should know her PIN”
• Standard PIN processing transactions, but multiple
  implementations from different vendors using
  hardware to keep PINs / keys from bank staff
• IBM made CCA manual available online
   – Excellent detailed description of API
   – Good explanation of background to PIN processing APIs
   – Unfortunately: lots of uncatalogued weaknesses.
            HSM Use in Banks

Acquiring       ATM Network            Issuing
  Bank                                  Bank
               HSM   HSM   HSM

   HSM                                  HSM

 HSM with
  keypad                         HSM

                                       Issuing Bank
                                       Regional HQ
     How are PINs Generated ?
Start with your bank account number (PAN)

                    5641 8203 3428 2218

Encrypt with PIN Derivation Key
(aka PMK – Pin Master Key)

                    22BD 4677 F1FF 34AC
Chop off the                                (B->1)
End                 2213                    (D->3)
      The Decimalisation Table
• Remember encrypted result was in hexadecimal
• Encryption produces output that looks uniformly
  distributed, so 0-F are all equally likely
• Decimalisation Table used to map 0-F back to 0-9
         digit in    0123456789ABCDEF
         digit out   0123456789012345
                    e.g. 22BD -> 2213
• Because some numbers have several hexadecimal
  digits mapped to them, they are more likely to occur
  in issued PINs than others
Collecting Frequency Distributions
       Example Distribution : HSBC












        0       1       2        3       4       5       6       7       8       9

Sample size: 45 people (just large enough to prove non-uniform hypothesis with 1% conf)
      How do I change my PIN?
• Most store an offset between the original
  derived PIN and your chosen PIN
• Example bank record…
  –   PAN          5641 8233 6453 2229
  –   Name                Mr M K Bond
  –   Balance                 £1234.56
  –   PIN Offset                 0000
• If I change PIN from 4426 to 1979, offset
  stored is 7553 (digit-by-digit modulo 10)
    Offset Calculation Attack (1989)
• Bank adds a new command to the API to calculate the
  offset between a new generated PIN and the customer‟s
  chosen PIN
• Possessing a bank account gives knowledge of one
  generated PIN. Any customer PIN could be revealed by
  calculating the offset between it and the known PIN

  U->C : Old PAN, Old offset, New PAN
  C->U : New offset
                  VSM Attack (2000)
• Top-level crypto keys exchanged between banks in
  several parts carried by separate couriers, which are
  recombined using the exclusive-OR function

       Source                                            Dest
        HSM                                              HSM

Repeat twice…                            Repeat twice…
                                         User->HSM   : KP1
User->HSM : Generate Key Component
HSM->Printer : KP1                       HSM->User   : { KP1 }ZCMK
HSM->User : { KP1 }ZCMK
Combine components…                      Combine components…

User->HSM   : { KP1 }ZCMK ,{ KP2 }ZCMK   User->HSM   : { KP1 }ZCMK ,{ KP2 }ZCMK
HSM->User   : { KP1 xor KP2 }ZCMK        HSM->User   : { KP1 xor KP2 }ZCMK
         Idea: XOR To Null Key
• A single operator could feed in the same part twice,
  which cancels out to produce an „all zeroes‟ test key.
  PINs could be extracted in the clear using this key

    Combine components…
    User->HSM    : { KP1 }ZCMK , { KP1 }ZCMK
    HSM->User    : { KP1 xor KP1 }ZCMK

    KP1 xor KP1 = 0
          Type System Attack (2001)
• ATMs are simpler than HSMs and have only one master
  key. ATMs need to be sent Terminal Communications
  keys (session keys) for link cryptography.

       HSM                                                 ATM
Master Keys                                            Master Key
TC – terminal communications                           TMK-ATM - used for everything
TMK – terminal master keys & PIN derivation keys
ZCMK – zone control master keys (between HSMs)
WK – working keys (session keys)
LP – local PIN storage key

                                           but how?
     { TC1 }TC                                        { TC1 }TMK-ATM
          Type System Attack (2)
• PIN derivation keys (PDKs) share the same type as Terminal
  Master Keys (TMKs), and encrypting communication keys for
  transfer to an ATMs uses exactly the same process as calculating
  a customer PIN – encryption with single DES.
           User->HSM     : TC1
           HSM->User     : { TC1 }TC
           User->HSM     : { TC1 }TC , { TMK-ATM }TMK
           HSM->User     : { TC1 }TMK-ATM

           The attack:
           User->HSM     : PAN
           HSM->User     : { PAN }TC
           User->HSM     : { PAN }TC , { PDK1 }TMK
           HSM->User     : { PAN }PDK1
VSM Type Diagram
How Type-System Attack Was Found
           Control Vectors
• IBM implementation, across many products since
  1992, of the concept of „type‟
• An encrypted key token looks like this :

IBM 4758 Key Hierarchy
              Key Part Import
• Thee key-part holders, each have KPA, KPC, KPC

• Final key K is      KPA KPB KPC

• All must collude to find K, but any one key-part holder can
  choose difference between desired K and actual value.
      4758 Key Import Attack
KEK2 = KORIG  (old_CV  new_CV)
Normally ...
DKEK1old_CV(EKEK1old_CV(KEY)) = KEY
Attack ...
DKEK2new_CV(EKEK1old_CV(KEY)) = KEY

IBM had known about this attack, documented it
obscurely, and then forgotten about it!
     Collision-Search Attacks

• A thief walks into a car park and tries to
  steal a car...

• How many keys must he try?
Car Park 1934
Car Park 2004
  Collision-Search Attacks (2)
• Capture-recapture statistics; also „meet in the
• Attack multiple keys in parallel, given a „test
  vector‟ (same plaintext encrypted under each key)
• Typical case: A 256 search for one key becomes a
  240 search for any one of 216 keys
• Any one key of a given type is usually enough -
  typical HSMs translate between keys of one type
• Poor implementations of 3DES (EK1, DK2, EK1)
  allow 3DES key halves to be attacked individually
   Collision Search Attack on HSMs
   • Generate 216 keys
   • Encrypt test vectors
   U->C : { KEY1 }KM
   C->U : { 0000000000000000 }KEY1

   • Do 240 search
Cryptoprocessor‟s Effort                      Search Machine‟s Effort

                16 bits                40 bits

                           56 bit key space
   Collision Search on 3DES
   A              Single Length Key
   A      A       Double Length “Replicate”

   X      Y       Double Length

   A      A            B          B

              A    B
The PRISM Security Module
  The Prism HSM Application
• 2 million South African pre-payment electricity
  meters credited not with coins but with magic
  numbers bought from vending machines at local
• Vending machines use Prism security module to
  protect vending keys from shop owners/burglars
• Discovering a vending key allows unlimited token
  manufacture = free electricity (until local meters
  are rekeyed)
• Vending keys stored in a hierarchy, with a
  manually loaded master key at top
           Master Key Entry
When vending machine first initialised…

• Three “trusted” security officers arrive with key
• Master key Km is a two-key 3DES key
• Each half loaded in three parts, which are
  exclusive-ored together
• Each security officer loads one part of each key
• Check digits returned per keypart after each load
         Check_Digitsi = { 0 }Kmi
          Example Key Entry
Security Officer 1
SM?IK 86 08F8E3983E3BDF26
SM!IK 00 916BA78B3F290101
SM!IK 00 0D7604EBA10AC7F3

Security Officer 2 (... n)
SM?AK 86 FD29DA10029726DC
SM!AK 00 EDB2812D704CDC34
SM?AK 87 48CCA975F4B2C8A5
SM!AK 00 0B52ED2705DDF0E4
                 The Faults
• Check digits are given on each half of the master
  key, so we can attack each half separately
• After master key is loaded, anyone can continue to
  exclusive-or in new parts to the master key
• We can load new parts and extract check values at
  line speed – unlike some other HSMs where you
  must use a trusted keyboard
• We can thus make a large set of related keys,
  discovery of any one of which lets us work back to
  find the master key
     Making the Related Key Set
For I = 0000000000000001
    to 000000000001FFFF
    SM?AK 87 I xor (I-1)
       SM!AK 00 (result)

       store the pair ( I , result )

Result : 2 x ½ MB files of test vectors
     Information Leakage Attacks
• Remember PINs derived from account numbers
• Hexadecimal raw PIN is converted to decimal using
  decimalisation table
• Most APIs allow the decimalisation table to be specified
  with each PIN verification command
• A normal verification command eliminates one of
  10,000 combinations of PIN for the attacker
• If the table is altered, whether or not the alteration
  affects correct verification leaks much more information
  about the PIN

         Decimalisation Table Attack (1)
  Encrypted PMK             PAN                Trial PIN
48CCA975F4B2C8A5      5641820334282218           0000


 1. Encrypt PAN
 Raw PIN = 22BD
 2. Decimalise
 Natural PIN = 2213
 3. Verify
 0000 != 2213

                         (eliminates 1 combination)
        Decimalisation Table Attack (2)
 Encrypted PMK              PAN                   Trial PIN
48CCA975F4B2C8A5      5641820334282218              0000


1. Encrypt PAN
Raw PIN = 22BD
2. Decimalise
Natural PIN = 0000
3. Verify
0000 = 0000

                     (eliminates all PINs containing digit 7)
  Decimalisation Table Attack (3)
• A surprising number of different attacks can be
  carried out by playing around with the
  decimalisation table and offset
• It seems everyone who understood HSMs thought
  up a different one once the basic idea was known!
• Generally, it‟s a „differential protocol attack‟ on a
  distributed computation. Can you tweak some
  (untrusted) inputs of a computation so that other
  (private) inputs are leaked?
• Very hard to stop in legacy systems
      PAN Modification Attack (1)
• Encrypted PINs transferred from ATM to issuing bank
  via ATM network using point to point encryption
• At each node PIN block must be decrypted with
  incoming key, and re-encrypted with outgoing key
• Common ISO standard “binds” PIN to particular
  customer by exclusive-ORing PAN with PIN before
• Attack: specifying incorrect PAN may make deduced
  PIN contain hexadecimal digit „A‟–‟F‟, which causes
  formatting error. Conditions under which formatting
  error arises leaks information about PIN

        Other API Attacks (1)
• Eli Biham – the GSM key management scheme
  creates a comms key Kc from a master key Ki and
  a challenge RAND
• Attack: observe RAND when phone using strong
  crypto, then replay it when weak crypto is in use
• Chris Mitchell: some HSMs allow MAC
  verification transactions to have variable-length
• Attack: incremental guessing
        Other API Attacks (2)
• Recent HSM transaction defined by VISA
  for EMV support
• Send key from HSM1 to HSM2 as {text |
  key} – where text is variable-length
• Attack – encrypt {text |00}, {text |01}, etc
  to get first byte of key, and so on
• Vulnerability turned up in multiple
The Last Word on ATM Security?
• The current ATM security architecture is fairly
  thoroughly broken, i.e. open to insider attack
• Banking security is concerned as much with
  liability as with cryptographic security – HSMs
  were bought so that customers could be blamed
• In Europe, banks are now switching to EMV
  (“Chip and PIN”) and rewriting their terms and
  conditions so that fraud is the customer‟s fault
• ATM security mechanisms were adapted to all
  sorts of other applications, such as prepayment
  electricity metering, that are now being fixed
• What next for security API research?
The First Word on Trusted Computing?
  • „Trusted Computing‟ proposals put simple
    hardware security modules in every PC
  • Also known as „Trustworthy Computing‟ and
    „Treacherous Computing‟ - see my TC FAQ
  • TC also encourages compartmentalisation of
    applications into trusted and untrusted components
    – just like ATM systems
  • Security API research may be able to help the
    interface designers avoid exploitable mistakes
  • Or maybe help you break into your PC after you
    buy it, to make it run the software you want
        A double-edged sword?
• IRM – Information Rights Management
    – Organisations - from Barclays to the Mafia - can stop
    – Microsoft can lock customers in tighter, and thus push
      up the price of Office
    – Software business could become more „normal‟ but at a
      cost in innovation, growth?
•   DRM – Digital Rights Management
•   Trusted IO – Enter your ATM PIN at your PC
•   Global PKI – All devices potentially indentifiable
•   Darknets and trusted anonymity systems
•   Trusted viruses
Example: Information Rights Management
   • Microsoft Office 2003 with
     Microsoft Rights Management Server
   • Will it be secure when supported by TC?

The “restrict” button
     The Future Digital Battlefield
             App1                       NCA1
Ring 2+                App2                      NCA2

           Services           Drivers
Ring 1

Ring 0                O/S                      Nexus

Hardware                                  TPM / SSC
     The Future Digital Battlefield
           DRM App                      DRM NCA
Ring 2+                App2                       NCA2

           Services           Drivers
Ring 1

Ring 0                O/S                     Nexus

Hardware                                   TPM / SSC
     The Future Digital Battlefield
           DRM App                       DRM NCA
Ring 2+                MyApp                       MyNCA

           Services            Drivers
Ring 1

Ring 0                O/S                      Nexus

Hardware                                    TPM / SSC
     The Future Digital Battlefield
           DRM App                         DRM NCA
Ring 2+               MyApp                          MyNCA

           Services              Drivers
Ring 1

Ring 0          O/S   (hacked)                   Nexus

Hardware                                      TPM / SSC
     The Future Digital Battlefield
           DRM App                         DRM NCA
Ring 2+               MyApp                          MyNCA

           Services              Drivers
Ring 1

Ring 0          O/S   (hacked)                   Nexus

Hardware                                      TPM / SSC
              Getting Formal
• How are we going to survive on this „battlefield‟ if
  all our technology is for attack, not defence?
• So far we have heuristics for understanding how to
  design security APIs, but there are important
  properties we would like to gain assurance about
  (in formal speak: “prove”)
• Formalising the specification of security APIs could
  help make properties clearer
• Semi-automated analysis of specifications could
  help in gaining assurance, locating vulnerabilities,
  and enumerating all instances of them
• We extended protocol analysis to security APIs, and
  broke almost every cryptoprocessor on the market
• If and when Trusted Computing arrives on our
  desktops, security APIs will become an integral part
  of secure application design
• We have a Cambridge-MIT Institute project with
  Ron Rivest to develop formal methods to cope with
  API problems. Other FM people should have a go
• But the problem is much wider and deeper than that.
  Differential protocol analysis is also new, and there
  are fascinating links emerging with composability
  and multiparty computation
            More Information
Papers, Links & Resources
Attacks on IBM 4758 CCA & Hardware Cracker
Trusted Computing
Cambridge-MIT Institute Pervasive Computing KIC

Shared By: