Whitepaper ax eft-kernel EMV Level 2 Kernel - a Software Module for EFTPOS Terminals

Transcription

1 Abrantix AG Förrlibuckstrasse 66 CH 8005 Zürich Tel.: Fax.: Whitepaper ax eft-kernel EMV Level 2 Kernel - a Software Module for EFTPOS Terminals Date March 30, 2009 Author Fabian Meier Version v1.0 Product Name ax-eft-kernel Status Released Classification Public Copyright Abrantix AG, 2009

2 Table of Content 1 Introduction Integrating a EMV Kernel: Challenges and Problems Technical Details of the Abrantix Ax-EMV Kernel Product Features Architecture EMV Kernel EMV Security Module (SCM) EMV Embedding Layer Security Processor Porting the Kernel System Requirements Development Environment (IDE) Compiler Public Key encryption & Hash implementation True Random Generator Implementation Steps Debugging with the Trace function during the development phase Integrating the EMV Kernel into a Terminal Application Services of Abrantix AG Administration Pre-Certification Adapting the kernel to your hardware Programming support / Application integration References Contact Page 2 / 16

3 1 Introduction What is the Abrantix EMV-Kernel The Abrantix EMV Kernel is designed to run basically any hardware platform. It supports the full functionality of all available EMV-Level 2 Kernel features, such as CDA, DDA, SDA, encrypted PIN, etc. It can be configured to your needs. The ax EFT Kernel is used by several terminal manufactures and it is running on many different hardware platforms. Using the ax EFT Kernel let you speed up your development work and allows you to reach a full certification within three months after project start. EMV Kernel in EFTPOS Terminals The Abrantix EMV Kernel (EMVK) is a configurable, highly portable software module, written in C, intended to be used on any 32 bit platform, running on any operating system. Target Audience Terminal manufacturers who would like to use an existing EMV Level 2 Kernel in order to integrate it with their existing terminal software. Key Features Property Details EMV Compliance EMV Level 2, v4.2a in progress (Summer 2009) Kernel passed v4.1e certification (Summer 2008) Highly configurable Kernel Highly Portable Security Module - Kernel supports all options described in the ICS (Implementation Conformance Statement - list of supported Kernel options). - Easy configuration of a specific ICS. Ansi C, no particular OS requirements, minimal external library dependencies The security critical code is in a separate module, and can be executed in a special security processor. Key Benefits Property Fast development Fast time to market Certification guaranty Stable approved kernel Details The Kernel can easily be integrated into your platform Using our Kernel you can launch a new product within weeks. Average project time is 4 month until receiving certification. (EMV estimates 18 month development time for a Level 2 Kernel) Our Kernel runs on many different platforms and is certified many times. Thousands of transactions are processed everyday through our customers using the ax EFT Kernel. Page 3 / 16

4 Figure: System Overview - Location of EMV Kernel in a Terminal Software Architecture Page 4 / 16

5 2 Integrating a EMV Kernel: Challenges and Problems Today many EMV implementations tightly integrate the EMV functionality with the payment application. Unlike other parts of a terminal application (for example a hardware driver), the EMV code needs periodic updating - required by adapting the EMV code to the newest EMV Level 2 standard. Especially the new EMVCo requirement to re-certify the EMV Level 2 functionality every three years requires the manufacturers to update their EMV kernel software constantly. For small and medium sized Terminal manufacturers it makes sense to evaluate whether a standard based functionality such as EMV Kernel functionality should be developed internally or purchased from an outside vendor. Challenges with developing and maintaining an internal EMV solution - Keeping up with EMV Standard (typically two updates every year) - Maintenance work - Very complex area of expertise - Mission critical component Advantages of using an external 3rd party solution - Rely on an existing solution that is being used by other terminal manufacturers - No need to spend time understanding all details of the highly complex EMV standard - An EMV Level 2 certification is not a key differentiator of a terminal solution - Faster time to market with a pre-certified EMV Kernel Page 5 / 16

6 3 Technical Details of the Abrantix Ax-EMV Kernel 3.1 Product Features Property Language Code Size EMV Standard Certification Details Ansi C - About 20k lines of code (source code) - About 64kB code size (with x86 gcc compiler) - EMV Level 2, v4.2a in progress (Summer 2009) - Kernel passed v4.1e certification Platform Any 32 bit platform (x86, MIPS, ARM,...) OS Required Libraries Required System Functions Security Processor Configuration Parallel EMV transactions possible RAM Memory Requirements API model Threading EMV Attributes - OS Independent. There is a small layer (common.h) that defines the view OS related calls. - No OS required. - C-Library (clib), no Math lib (no floating point numbers used, only integers) - SHA-1, RSA (SCM module) - SHA-1 (EMV Kernel) True Random number generator, according to terminal requirements (possibly PCI specifications). The key loading and storing mechanism, and the pin input access can be implemented in a secure processor. - Fully configurable kernel. One data struct defines the complete EMV Kernel configuration, and the capabilities of the terminal Yes. Each transaction has one "context" (a struct/object with all state variables in it). - About 4kB per context (= per transaction instance). - Additional: size of a public key per application (max. 256 Bytes). Note: CA Public keys are stored in the application - they are accessed each time a transaction happens. Application code calls EMV module functions. No blocking calls. Each call gets finished in a relatively short time - no waiting involved. No callback model. Application can be run single threaded. All function calls are nonblocking. Application can access (set/get) EMV attributes of the Kernel. Page 6 / 16

7 Some of the supported EMV options Functionality Offline Data Authentication CVM Configurable Options Risk Management Details SDA, DDA and CDA Standard CVM's - Attended/Unattended Terminal Type - Online Data Capture - Issuer Code Tables - Velocity Checking - Random Selection - Transaction Log Page 7 / 16

8 3.2 Architecture The Abrantix EMV Kernel consists of four components: Component EMVK - Kernel SCM - Security Module EMVE - Embedding Layer Utility library Details All EMV processing is done here. This code does NOT need any modification. Code that runs in the security module and manages 1. key loading and storing 2. Gets the Pinpad data in plaintext (direct connection to the PINPAD driver) This code needs to be adapted, or is already existing. Layer that controls the EMVK and the SCM. Interface to the application code, and also interface to the ICC driver. Functions that have no direct EMV functionality, such as: - bcd calculations - Layer to common encryption/hash functions (SHA, etc). The encryption is NOT in this library - linked list implementation The EMV functionality is split up into two components: the EMV kernel module, which is intended to run on a main processor MCU and the EMV security module, which will run on the security processor, if applicable. The code that controls the EMV kernel module and the security module is called the EMV Embedding layer. The EMV Embedding layer communicates with the terminal payment application, and needs to be adapted to each terminal. A working code sample is part of the SDK. The EMV module can run in a single threaded application Page 8 / 16

9 Figure: Detailed view of the EMV Module, inside a terminal EMV Kernel All the EMV relevant operations are done in this module. This part of the code needs no modification at all. If the Kernel needs a re-certification after three years, this code will be replaced with the new version without changing the application. A Structure/Object named EMV_CONTEXT contains all state variables of one EMV transaction. With more than one EMV_CONTEXT instances, it is possible to process more than one EMV cards in parallel. All states of the Kernel are preserved in this instance. The EMV kernel does not require any libraries or other modules to operate. Page 9 / 16

10 3.2.2 EMV Security Module (SCM) The SCM implements the certificate chain validation and PIN encryption methods required for EMV. It may or may not run on a dedicated security processor. The EMV Security Module (SCM) performs the following tasks: - It stores the CA public keys. Key loading is not part of this interface, but it is assumed that EMV CA keys are loaded securely as part of application initialization. Each key is identifier by its { RID, Index } bytes. - Certificate chain validation down to issuer or ICC/Pin encryption certificate, depending on the selected offline authentication method. During this task, issuer, ICC and PIN encryption keys are be loaded into a key handle for subsequent operations. - PIN encryption for Offline-PIN CVM. - Public key operations on the keys loaded during chain validation EMV Embedding Layer This component controls the EMV Kernel and the EMV Security Module. It is also the interface to all other system components, such as: - File reading/writing (keys) - Communicating with the EMV chip reader driver (ICC interface) - Getting the PIN data in plaintext from the PINPAD driver Figure: Interaction between the terminal application and EMV kernel (typically implemented in the EMV Embedding layer). 3.3 Security Processor The SCM functionality may run in a security processor, in order to be PCI compliant. Page 10 / 16

11 The security processor is a separate processor with the following properties, in order to guarantee secure transaction (part of the PCI requirements for a terminal): - RAM that cannot be accessed from the outside - Processing of data without observing the register values, for example a debugger cannot see the data in the MCU. 3.4 Porting the Kernel System Requirements - OS independent (The Kernel has been ported to Linux, Windows, Windows CE, a Proprietary Embedded OS) Development Environment (IDE) - No specific IDE is required - Project Files for Microsoft Visual Studio are provided - Build: Linux/Posix Makefile are provided - in cygwin environment on Windows the Unix "make" command is the recommended build tool. However, this is not a hard requirement at all - the Makefile can be adapted to various build environments. The Makefile is quite simple and easy to port Compiler Any Ansi-C compiler can be used to compile this module. Compilers used in current projects: - gcc (Linux Environment) - Windows C compiler (Microsoft Visual Studio environment) List of all the files and what adaption they need Files Details Modification required Makefile Required to build all modules Yes common.h Interface to OS calls/platform dependent Yes emv_tags.h emv_tags.c emv_tags.names.i Tags specific to the EMV Standard. emv.h Header file to EMV Kernel No emv_k_*.c emv_k_*.c EMV Kernel. emv_s_scm.h Header file to EMV Security Module No (?) emv_s_main.c EMV Security Module Possible. Reference Implementation. No No Can be used as it is, or totally Page 11 / 16

12 bcd.h, bcd.c der.h, der.c list.c debug.c emv.c emv_sk_hash.c Utility library rewritten bcd.c/h: No der.c/h: No list.c: No debug.c: No (depends on platform) emv.c (??? emv_sk_hash.c: Yes (wrapper for SHA-1 hash and public key encryption functions) Public Key encryption & Hash implementation The following public key encryption algorithms are needed: EMV Kernel: SHA-1 SCM: SHA-1, RSA. In our reference implementation we are using the on OpenSSL implementation. However, if the terminal has this functionality implement in hardware or an already existing library - these external functions can also be used by the EMV kernel True Random Generator According to EMVCo the EMV Kernel requires a true random generator - typically the system (Terminal hardware) provides this functionality Implementation Steps 1. Adapt the OS layer: common.h 2. Make sure the build works - adapt Makefile 3. Adapt the EMV Embedding - interface to existing EFTPOS application. This is specific to the current terminal implementation. Use the Embedding sample code. This part involves sending and receiving data to/from the ICC (EMV card driver). 4. Adapt the EMV Security Module. Possibly a rewrite is required - depends on the Security Processor of the current platform. Use the existing code as a starting point. 5. Use / add a encryption and hash library. 6. Add the random number generator. 7. The EMV Kernel does NOT need any adaption or changes! 8. EMV certification of the complete terminal Debugging with the Trace function during the development phase In order to efficiently debug and develop the code, a debugging facility had been added to trace the activity of the code. "Trace" has the same meaning as "Logging". The debug output is sent to SDTOUT, with the TRACE() macro. The implementation of the TRACE macro is done in common.h Page 12 / 16

13 A number of flags can be turned on and off, in order to create debug output. Simply set the value to 1 to enable tracing or 0 to disable tracing. Setting the trace flags is done with the global variable EmvTraceFlags. 3.5 Integrating the EMV Kernel into a Terminal Application The main effort is to integrate EMV Embedding layer with the existing terminal application. However, the interaction between the embedding layer and the terminal application is very minimal and straight forward. Each call to the Embedding layer is a non-blocking call. The kernel runs in the same thread as the main application. Each call gets returned right away. This means that a transaction can be canceled any time, the application has full control of the kernel at any moment. The kernel requests during each transaction all the available EMV applications from the terminal application. Abrantix provides a working reference code for the EMV embedded layer. Page 13 / 16

14 4 Services of Abrantix AG Abrantix offers a wide range of services that can even more speed up your terminal development. These services vary from administrative help to technical integration support. We also can help with our long experience in terminal programming to get your software running. All these services are offered on demand. Please ask for your quote. 4.1 Administration The administrative process for a kernel certification is very complex. Abrantix helps you with the application, the EMV Contract, finding the right Kernel configuration and filling out the EMV ICS (Implementation conformance statement). We basically do the full paperwork under your name. 4.2 Pre-Certification Abrantix has a lot of EMV-Test-Tools that help you to integrate the kernel into your application and run pre-certification test against your environment. 4.3 Adapting the kernel to your hardware We can help you to adapt the kernel to your specific hardware. 4.4 Programming support / Application integration Since we have realized many payment application and many payment protocols, we have a large toolbox that can help you speed up your development. Page 14 / 16

15 5 References Existing Applications of the Abrantix EMV Kernel: - Eftpos applications in Switzerland (Linux, 32bit Arm) - Bank Teller Pinpad terminal (2 large customers, Swiss Banks, Linux, 32bit Arm) - Card processing for a parking garage solutions (more than 50 customers, Windows XP, x86) - Secure Processor in a new EFTPOS terminal, (32 bit MIPS, no OS) - Company internal simulators for testing (Windows XP, x86) Page 15 / 16

16 6 Contact For more details we are happy to talk to you personally. Please contact: Abrantix AG Herr Christian Vetsch Förrlibuckstrasse Zürich Switzerland Telefon: Internet: Page 16 / 16