verification_slides

1. Introduction Java Cards An augmented bytecode verifier Java Card Bytecode Verification Designing a new verification system Alessio Parzian European Institute of Innovation and Technology University of Twente Security & Privacy August 5, 2015 Alessio Parzian Bytecode Verification

2. Introduction Java Cards An augmented bytecode verifier Contents 1 Introduction Mobile devices and payments The secure element The management issue 2 Java Cards In a nutshell Attack vectors 3 An augmented bytecode verifier Requirement analysis A new scenario Technicalities Alessio Parzian Bytecode Verification

3. Introduction Java Cards An augmented bytecode veriﬁer Mobile devices and payments The secure element The management issue “The convergence of payments and mobile communications is not just logical – It is inevitable” – John Coghlan, Ex CEO Visa USA −→ Contactless payment adoption −→ Mobile device ubiquity −→ Expanded mobile functionalities Alessio Parzian Bytecode Veriﬁcation

4. Introduction Java Cards An augmented bytecode verifier Mobile devices and payments The secure element The management issue Figure 1 A physical secure element (SE) in an Android mobile device. → NXP Solution: Java Card SE + NFC Definition Protected area, independent from the application processor of the device, which is capable of storing and processing sensitive information of the device holder. Services Authentication, encryption of private data, data integrity and non-repudiation are typical services that a secure element provides. Alessio Parzian Bytecode Verification

5. Introduction Java Cards An augmented bytecode verifier Mobile devices and payments The secure element The management issue Figure 1 A physical secure element (SE) in an Android mobile device. → NXP Solution: Java Card SE + NFC Definition Protected area, independent from the application processor of the device, which is capable of storing and processing sensitive information of the device holder. Services Authentication, encryption of private data, data integrity and non-repudiation are typical services that a secure element provides. Alessio Parzian Bytecode Verification

6. Introduction Java Cards An augmented bytecode veriﬁer Mobile devices and payments The secure element The management issue The parties involved Card Manufacturer Authority that fabricates the raw hardware and software. Card Issuer Authority that controls the secure element content. Application Developer Authority that implement applets. Alessio Parzian Bytecode Veriﬁcation

9. Introduction Java Cards An augmented bytecode verifier Mobile devices and payments The secure element The management issue The ideal SE initialization and management Card Issuer can add libraries onto an SE as needed Card Issuer can outsource freely the development of applets A SE is largely customizable by end users who can install applets as needed → Applet Market Applets from different Card Issuers can be installed on the same SE A SE is as flexible as a mobile operating system, but more secure → Java Card has all the features to allow that! → Dynamism and Multi-application. Alessio Parzian Bytecode Verification

10. Introduction Java Cards An augmented bytecode verifier Mobile devices and payments The secure element The management issue The current SE initialization and management A Card Issuer asks NXP to initialize a security domain on a SE A Card Issuer hands libraries/applets to be installed to NXP NXP verifies the requested software and installs it onto the SE The SE is released and will not be further personalized Alessio Parzian Bytecode Verification

11. Introduction Java Cards An augmented bytecode verifier Mobile devices and payments The secure element The management issue Too many drawbacks 1 Not enough flexibility No post issuance uploads No multi-application Strong relationship between a SE manufacturer and a card issuer required 2 Card Issuer are looking for new solutions → Host-based card emulation 3 Potential of Java Card SE only partially used Alessio Parzian Bytecode Verification

17. Introduction Java Cards An augmented bytecode verifier Mobile devices and payments The secure element The management issue As a SE manufacturer, NXP Semiconductors, is strongly interested to invert this trend. But how can this be achieved? 1 Studied advantages and weaknesses of Java Card 2 Classified its current vulnerabilities and attacks vectors 3 Analyzed stakeholders business requirements 4 Designed an innovative applet verification system Alessio Parzian Bytecode Verification

22. Introduction Java Cards An augmented bytecode verifier In a nutshell Attack vectors Architecture Applet Applet Applet Java Card Framework APIs Java Card Virtual Machine Native Operating System Underlying Hardware Smartcard (On-card) Card Acceptance Device (CAD) Host application Host/PC (Off-card) responses com m ands Java Card Runtime Environment Backend Application Remote server responses commands Figure 2 The Java Card smartcard architecture Alessio Parzian Bytecode Verification

23. Introduction Java Cards An augmented bytecode verifier In a nutshell Attack vectors Benefits - Interoperability, developed applets can be run on any Java-enabled smartcard. - Multi-application, multiple applets can reside on the same smartcard. - Dynamism, applets can be added after a smartcard issuance. - Enhanced security, built-in dedicated security mechanisms are deployed in the architecture. Alessio Parzian Bytecode Verification

24. Introduction Java Cards An augmented bytecode verifier In a nutshell Attack vectors Defined a new nomenclature and classified attack vectors by vulnerability. Hereafter the most relevant: 1 Power Analysis and Manipulation - Differential Power Analysis - Fault Injection 2 Applet Exploitation - Hidden commands - Unchecked parameters - Unsafe crypto protocols 3 Type Confusion → byte == short ?? - Obtaining the right to load code - Injection of ill-formed code - Run a developed attack vector Alessio Parzian Bytecode Verification

27. Introduction Java Cards An augmented bytecode verifier Requirement analysis A new scenario Technicalities The concept Oracle Verifier CAP Export files Additional Checks Typed verification over export files Transaction module Fault Injection module . . . Signing System Device’s Secure Element Figure 3 The Off-card verifier working principle Research Question How can we design a process such that an augmented bytecode verifier can be used to provide a flexible and highly-secure system for applet installation? Alessio Parzian Bytecode Verification

28. Introduction Java Cards An augmented bytecode verifier Requirement analysis A new scenario Technicalities Business requirements and their impact Priority Major Moderate Minor Requirement 1. Hostile Environment 2. Verification enforcement 3. Flexible relationships 4. Code confidentiality 5. Transparency 6. Uploads monitoring Table 1 Stakeholders’ business requirements priority Alessio Parzian Bytecode Verification

29. Introduction Java Cards An augmented bytecode verifier Requirement analysis A new scenario Technicalities A system story Assumption: SEs already initialized and released CI → NXP Service Request NXP → CI Augmented bytecode verifier release CI Libraries development, verification, upload CI → AD Applet development outsourcing CI → NXP Service request for AD NXP → CI → AD Augmented bytecode verifier release AD Applet development, verification, upload EndUser Applet download, installation Alessio Parzian Bytecode Verification

38. Introduction Java Cards An augmented bytecode verifier Requirement analysis A new scenario Technicalities Phases identification Stakeholders have different requirements, different roles, different resources and are numerically distant. Therefore, they must be treated separately to be much more effective in designing the system architecture. Three phases for each stakeholder can be identified: - Activation, which refers to the moment where a new stakeholder registers into the service. - Usage, which refers to the phase where content, intended to be uploaded onto one or more secure elements, is verified. - Distribution, which refers to the step of uploading a verified content onto one or more secure elements as needed. Alessio Parzian Bytecode Verification

39. Introduction Java Cards An augmented bytecode verifier Requirement analysis A new scenario Technicalities A system story from a card issuer perspective Assumption: Focus on the Usage phase CI → NXP Service Request NXP → CI Augmented bytecode verifier release CI Libraries development, verification, upload CI → AD Applet development outsourcing CI → NXP Service request for AD NXP → CI → AD Augmented bytecode verifier release AD Applet development, verification, upload EndUser Applet download, installation Alessio Parzian Bytecode Verification

40. Introduction Java Cards An augmented bytecode verifier Requirement analysis A new scenario Technicalities The system distributed architecture I Card Issuers 1..N Verifier 1..N Verified CAP Database Location 1..N NXP backend Verifier Licenses Certificates Signed Export Files (JCOP,lib,app) Location α Entities Cardinality NXP - Card Issuer → 1:N NXP - Verifier→ 1:N Card Issuer - Verifier→ 1:1 Trusted Area Untrusted Area 1. CAP export file 6. Signed CAP 7. Signed CAP upload 2. License verification oncard exp file applet retrieval 4. Report final process outcome 5. Upload of the signed applet export files 3. Verification modules Figure 4 The distributed architecture from the Card Issuer perspective Alessio Parzian Bytecode Verification

41. Introduction Java Cards An augmented bytecode verifier Requirement analysis A new scenario Technicalities A system story from an application developer perspective Assumption: Focus on the Usage phase CI → NXP Service Request NXP → CI Augmented bytecode verifier release CI Libraries development, verification, upload CI → AD Applet development outsourcing CI → NXP Service request for AD NXP → CI → AD Augmented bytecode verifier release AD Applet development, verification, upload EndUser Applet download, installation Alessio Parzian Bytecode Verification

42. Introduction Java Cards An augmented bytecode verifier Requirement analysis A new scenario Technicalities The system distributed architecture II Application Developer 1..N Verifier 1..N Location 1..N Card Issuer 1..N Verified CAP Database Certificates Application Developers Location a..z NXP backend Released Verifier Licenses Certificates Signed Export Files (JCOP,applets) Location α Entities Cardinality NXP - Card Issuer → 1:N NXP - Verifier→ 1:N Card Issuer - App. Developer→ 1:N App. Developer - Verifier→ 1:1 Trusted Area Trustworthy Area Untrusted Area 1. CAP export file 7. Signed CAP 8. Signed CAP forwarded 9. Signed CAP file resigned and uploaded 4. Card issuer cryptographic confirmation for uploading 2. License verification oncard exp file applet retrieval 5. Report final process outcome 6. Upload of the signed applet export file 3. Verification modules Figure 5 The distributed architecture from the Application Developer perspective Alessio Parzian Bytecode Verification

43. Introduction Java Cards An augmented bytecode verifier Requirement analysis A new scenario Technicalities The protocol concept Components: augmented bytecode verifier, Java Card token, NXP backend Remote secure tunnel between the Java Card token and NXP backend → monitoring the verifier Local secure tunnel between the Java Card token and the verifier → avoid MITM attacks Use of finite automata to enforce states Use of timers to further decrease the attack surface Cryptographic confirmations from a Card Issuer and NXP before signing → Security centralized in NXP hands → Distribution left in Card Issuers hands Alessio Parzian Bytecode Verification

50. Introduction Java Cards An augmented bytecode verifier Requirement analysis A new scenario Technicalities From inside the verifier MAIN EXECUTION 1. CAP file 1. Exp file 10. Signed CAP file 10. Signed Exp file Modules 1 .. k Java Card Token App. Developer Location 2.Licenseverification 3.Runmodules 4.Magicnumbers 5.Cryptoconfirmation6.NXPreport 7. CAP,exp 8. Signed CAP,exp 9. Exp upload Figure 6 The augmented bytecode verifier at the Application Developer location Alessio Parzian Bytecode Verification

51. Introduction Java Cards An augmented bytecode verifier Requirement analysis A new scenario Technicalities Security mechanisms to counteract white-box attacks Binary Encryption Code Obfuscation and Flattening On disk In memory Executing Verifier Code Variables Constants Keys Figure 7 States of the software attackable in a white-box scenario White-box Cryptography Runtime Integrity Check Alessio Parzian Bytecode Verification

56. Introduction Java Cards An augmented bytecode verifier Requirement analysis A new scenario Technicalities Runtime Integrity Check Threat An attacker is able to modify a check with another self-implemented module NXP m2 Main execution h Token Build module M from m1 and m2 Run M Compute Magic Number → session dependent Compute Hash h Send h to the token for verification Alessio Parzian Bytecode Verification

57. Introduction Java Cards An augmented bytecode verifier Requirement analysis A new scenario Technicalities White-box Crypto Threat An attacker is able to perform a MITM attack between the main execution and the token Lookup tables lt Main execution Session key sk Token Bidirectional tunnel Symmetric cryptography Secure tunnel between NXP and token → sk and lk securely delivered Main Execution is an untrusted entity → white-box crypto using fixed key approach Lookup tables initialized each session according with sk Alessio Parzian Bytecode Verification

58. Introduction Java Cards An augmented bytecode verifier Requirement analysis A new scenario Technicalities Edge cases It is not feasible to forecast the effects of a breach in a White-box scenario, thus security mechanisms to deal with edge cases must be designed. 1 Key Renewability 2 License Revocation 3 Verifier Binary Diversity Alessio Parzian Bytecode Verification

62. Introduction Java Cards An augmented bytecode verifier Requirement analysis A new scenario Technicalities Implementation Direction Modules in Java High-level language Portable binaries Oracle verifier source Main Execution in C Effective obfuscation/flattening Less reversible More complex Communication through JNI Even if modules can be considered as conceptually independent piece of software from the main execution, they are strongly interconnected and controlled by means of our runtime integrity check mechanism proposed and the two involved trusted party, NXP and token, which can monitor the correctness of the operations throughout the entire process of verification. Alessio Parzian Bytecode Verification

63. Introduction Java Cards An augmented bytecode veriﬁer Requirement analysis A new scenario Technicalities Thank you for your Attention. Alessio Parzian Bytecode Veriﬁcation

64. Introduction Java Cards An augmented bytecode veriﬁer Requirement analysis A new scenario Technicalities Thank you for your Attention. Alessio Parzian Bytecode Veriﬁcation

65. Introduction Java Cards An augmented bytecode verifier Requirement analysis A new scenario Technicalities Content Outline 1 Introduction Mobile devices and payments The secure element The management issue 2 Java Cards In a nutshell Attack vectors 3 An augmented bytecode verifier Requirement analysis A new scenario Technicalities Do you have any questions? Alessio Parzian Bytecode Verification

66. Introduction Java Cards An augmented bytecode veriﬁer Requirement analysis A new scenario Technicalities A new nomenclature A nomenclature that covers all feasible classes of attacks on Java Cards, namely logical attacks, physical attacks and side channel attacks. Each class introduces, at a high level, feasible attack types grouped by vulnerabilities along with the common countermeasures that should be taken to counteract those attacks. Alessio Parzian Bytecode Veriﬁcation

67. Introduction Java Cards An augmented bytecode verifier Requirement analysis A new scenario Technicalities Scenario Properties 1 The verification process is successfully completed 2 CAP and export files preserve their integrity after verification 3 Stakeholders are always authenticated prior to any action to avoid unwanted behaviours 4 Revocation can be always applied to avoid relevant failures 5 The augmented bytecode verifier is strongly resilient to white-box scenario attacks Alessio Parzian Bytecode Verification

verification_slides

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Similar to verification_slides

Similar to verification_slides (20)

verification_slides