Requirements
This is the set of requirements that switstack moka
realizes.
Requirement | Description |
---|---|
Req-1 | An EMV Level 2 stack shall be open. |
Req-2 | An EMV Level 2 stack shall be testable and certifiable. |
Req-3 | An EMV Level 2 stack shall be programmable and maintainable. |
Req-4 | An EMV Level 2 stack shall be fast. |
Req-5 | An EMV Level 2 stack shall be secure. |
Req-6 | An EMV Level 2 stack shall be independent from hardware platform. |
Req-7 | An EMV Level 2 stack shall be independent from physical architectures. |
Openness
switstack moka
is a Source-available Software EMV Level 2 project. It is released through a source code distribution model that includes arrangements where the source can be viewed, and in some cases modified.
It is platform agnostic, and written in C99 for maximum hardware compatibility with minimum external dependencies.
(see also License).
Testability and Certifiability
Testability
refers to architecture principles that have been followed to make switstack moka
testable:
- Service-based design: each kernel is a service that shall be integrated through a message broker. This architecture pattern limits the coupling between the software components participating to scaffold the EMV Level 2 stack.
- No concurrency: some EMV Level 2 specifications may suggest that concurrent tasks could collaborate to process EMV cards. But that approach wouldn't guaranty predictability in terms of sequences of execution.
switstack moka
is an implementation of EMV Level 2 specifications that takes the form of a sequential execution of EMV processing steps.
Certifiability
refers to switstack moka
's Software Development Life Cycle (SDLC) aiming that milestone.
switstack team and colloborating organizations maintain switstack moka
all along the year based on specifications, bulletins, and tools updates. The underlying objective is to have a software system that can be submitted to certification at any time of the year by switstack moka
adopters.
(see also Software Defined Architecture).
Programmability and Maintainability
Programmability
switstack moka
is programmable in a sense that it exposes a framework and a set of API that enables a high level of specialization by an external organization without comprimising its stability. It comes with a series of documents and tools to make this EMV Level 2 stack as comprehensive as possible for any EMV solutions developments.
Maintainability
An EMV Level 2 requires a lot maintenance along. It is important to put in place a systematic way of coding and debugging. switstack moka
promotes a high level of traces that enable an easy mapping between lines of code and specifications. The ultimate goal is to deliver a maximum autonomy to switstack moka
adopters.
(see also Coding Patterns).
Performance
EMV Level 2 contact certification doesn't have any requirements in regards to performance. Even if this topic of discussion was major in the context of the US migration during the past decade, it was more a concern about user experience, or EMV Level 3 integration.
For EMV Level 2 contactless certification, that topic is crucial. There are 3 aspects that impact the global performance of an EMV Level 2 stack:
-
The EMV Level 2 specifications: the earlier a card can be removed from the field, the faster the card processing completes at the point of interfaction. Typically, there are 2 kind a specifications that rules the contacltess acceptance. This aspect is independent from
switstack moka
implementation. -
The physical architecture: in general, the closer the EMV Level 2 stack execution is from the NFC antenna, the faster the exchanges between a point of interaction and a card are. There is - a least - one known exception to this observation: should you need to implement an EMV Level 2 in java on a secure element that drives an NFC antenna, this may be a challenge to achieve performance objectives. This aspect is independent from
switstack moka
implementation. -
The data processing: this relates to the design of the stack. This is where
switstack moka
makes a difference: - C implementation
- No dynamic memory allocation
- Optimized data parsing for ASN1
(see also Architecture).
Security
Security, in particular sensitive data protection, is not a requirement addressed by EMV Level 2 specifications on the terminal side. Whereas an EMV Level 2 certifciation focuses on data structures and how they shall be processed, the management of sensitive information is not at stake. This perspective is exclusively captured in the scope of PCI certifications. However, switstack moka
project aims at tackling this problem as early as possible to ease EMV Level 2 integration and deployment. The main risk related to the design of an EMV Level 2 stack is the dissemination of data such as the PAN. That risk is increased by the fact that switstack moka
doesn't make any hypothesis on the physical architectures hosting it (see physical architecture agnosticity requirement).
As a result, sensitive data are detected, captured, and obfuscated at the source, i.e. as clause as possible to the EMV Level 1 layer. It is up to the implementer to decide where and how this should be realized on the targeted platform. This part is covered by the Reader
that is the service to port along with the Hardware Abstraction Layer (HAL).
(see also Sensitive Data Protection).
Hardware Platform Agnosticity
switstack moka
leverages on a HAL like most of the EMV Level 2 stacks. It is worth to mention that switstack moka
's HAL is not designed as a service but as an API. It provides several abstracted group of functions such as:
- Cryptographic functions (random generation , rsa, sha, ecc, ...)
- EMV functions (card interface, terminal management)
- OS functions (rtc, string, i/o, memory, ...)
(see also Integration).
Physical Architecture Agnosticity
switstack moka
project was born in the context of the emergence of softPOS solutions. COTS devices, running such software systems, don't need to be EMV Level 1 certified. This characteristic openned the door to what is known as kernel-on-cloud
. This kind of physical architecture was popular in the context of EMV contact solutions deployed along with a thin client. But, it is now possible to promote such architecture for COTS-based contactless acceptance.
Consequently, switstack moka
was designed around a message broker. Even if most of the use cases will be PCI-PTS, it is possible to distribute some services and manage a centralized EMV Level 2 processing thanks to this architecture pattern.
(see also Architecture).