1 / 11

API-Level Attacks on Embedded Systems By Mike Bond and Ross Anderson

Mark Cheuk Fun Chan. API-Level Attacks on Embedded Systems By Mike Bond and Ross Anderson. “… by presenting valid commands to the security processor, but in an unexpected sequence, it is possible to obtain results that break the security policy its designer envisioned.”. Outline. API

aizza
Download Presentation

API-Level Attacks on Embedded Systems By Mike Bond and Ross Anderson

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Mark Cheuk Fun Chan API-Level Attacks on Embedded SystemsBy Mike Bond and Ross Anderson “… by presenting valid commands to the security processor, but in an unexpected sequence, it is possible to obtain results that break the security policy its designer envisioned.”

  2. Outline • API • Cryptographic processor • How automatic teller machine (ATM) encryption works • API-Level Attacks • Conclusion

  3. API • Application Programming Interface (API) • Cryptographic processor’s API • Transaction set  a group of commands supported by the processor to manipulate and manage sensitive information, usually cryptographic keys. • Very insecure • All transactions and procedures have to go through there. • “No matter what the application of the processor, its API sits on the boundary between trusted and untrusted environments”

  4. Cryptographic Processor • Cryptographic Processor • Contains one or more cryptographic keys • Build around machines or used in Network • Prevent Interception and modification!! • Crucial to ATM machine • Tamper-resistant processor: “Security module” • contains cryptographic keys used for communication & verifying PINs.

  5. Cryptographic Processor • First-Generation Product • IBM3848 • Support encrypted communications between mainframe and terminal. • Use tamper-resistant memory to hold all the crypto keys • Second-Generation Product • Visa Security Module (VSM) • Protect PIN transmit over bank’s ATM networks and Visa’s network. • First priority of the design: ensure no employees of any bank can learn about the customer’s PIN

  6. How ATM encryption works Account Number: 8807012344678 PIN (derivation) key: EFEFFEFEFEFEF Result of DES: A2CE12698GNGN Result of decimalized: 02243472070995 Natural PIN: 0224 Offset : 6565 Customer PIN: 6789

  7. Known-key Attack Bank’s central VSM HOST “Generate key share” “Generate key share” “Combine keys” XOR Terminal Master Key 0…..00

  8. Two-Time Type Attack • Cryptographic processor enforces type system on keys • 3 key types in 3848  9 keys types in VSM • Still not enough!! • Terms: • Customer’ primary account number (PAN) • Master key (KM) • PIN derivation key (KP)  {KP}KM • Terminal Master key (KMT)  {KMT}KM • Terminal communication key (KC)  KMC

  9. Two-Time Type Attack • Customer PIN  {PAN}KP • KMT is the same type as KP • First Step • Host  VSM: “Encrypt key”, PAN • VSM  Host: {PAN}KMC • Second Step • Host  VSM: “KC to KMT”, {PAN}KMC, {KMT}KM • Host  VSM: “KC to KMT”, {PAN}KMC, {KP}KM • VSM  Host: {PAN}KP

  10. Two-Time Type Attack • General problem with many common key-typing system. • Once a key of certain type is compromised, all material at the next level down the hierarchy can also be compromised. • Even worse in VSM • Terminal master key is used to encrypt communication keys

  11. Conclusion • Learning how to design security API properly is important • Poor design prevents tamper-resistant processor to perform • Design failures may lead to tremendous loss • Rectifying mistakes can be horrendously expensive. Do you think “Two-time type” attack can be avoid?? If you do, do you think by just rectifying the vulnerability of the API would be enough??

More Related