The nexoid-ed from hurufu

Implement "Contactless Application Kernel Profile Selection"

As described in nexo-FAST v.3.2 section 7.4.2.1

Generate stubs.c for windows builds

Right now stubs.c is hand-coded, but this approach is suboptimal, because this file has to be modified each time new procedure is added or removed from the lib. Consider generating this file from nm -u output. Custom script may be required.

Finish "Financial Application Startup" as described in nexo-FAST v.3.2 note 15-10

Low priority

Implement `Match_Prefix_Range`

Section 7.4.2.4 procedure Match_Prefix_Range.

Refactor "Technology Selection – Separate Readers"

Low priority, but specification is maddening.

Implement `Match_Aid`

Add tests and implement Match_Aid in section 7.4.2.5.

Consider rewritting bussiness logic in Ada

Ada is a strongly typed language that is well suited for describing Nexo specification.

Pros:

Very-strong type checking
Well defined bit fields that are used a lot in EMV and Nexo.
Preconditions and postconditions that actually are there in the nexo specification, and it would be nice to have them. They usually state which variables must change their value or must only be read.
Maps well from Drakon
1. it has goto which is needed for blazing fast implementation
2. high-level looping constructs compared to C
3. nested function which may be used to implement procedures/functions with multiple entry points

Cons:

I have to implement Ada generator from Drakon diagram
I have to learn Ada well enough to be able to design this generator properly
There aren't many free and open source ASN.1 compilers for Ada.

References:

Finish "Chip Profile Selection"

As described in nexo-FAST v.3.2 section 7.4.2.5

Consider converting bussiness logic from C to C++

As time goes I begin to see issues that aren't easily solvable in C. They can be roughly divided into 2 categories:

Technical
1. Porting to Windows - this is big one, right now it's impossible to create DLL, without trying to jump over your head.
2. Testing - Right now in order to test nexoid-ed it's needed to defined interface symbols for a test. Basically that means that in a single executable can be only single implementation of APIs (SCAPI, HAPI etc), which defies the point of testing, because normally we want to test different scenarios, like failure in a particular API call, etc. There is still a possibility to connect API to some scripting language and work with that, but for now experiments with libctl failed (#2).
Non-technical
1. Readability
  1. Operator overloading - It can simplify look of executable diagrams, which was the main point of them in the first place. ttd.transactionAmount > 1 is way more readable for non-programmer than amount_compare(ttd.transactionAmount, create_bcd(1)) > 1 or something similar.
  2. Implicit memory handling - It was solved partially using ptmalloc3 and memory pools, but still one have to use special macros acpval and acpptr to allocate a copy of a variable. This can be simplified with custom allocators in C++

Implement "Card Removal Process – Separate Readers"

It's described in nexo-FAST v.3.2 section 7.3.2.1.3.

Skip formatting errors for some tags

In EMV Book 3, section 7.5 it is specified that terminal may ignore formatting errors for some tags like Cardholder Name (5F20). TODO: Check if nexo also supports this.

Implement BIN filtering for DCC transactions

Section 6.6 procedure Transaction_Dcc_Eligibility

Implement "Cardholder Application Confirmation"

As described in nexo-FAST v.3.2 section 7.4.2.2.6

Consider replacing `ttd` with a pointer

This is a major refactoring, but may be done quite mechanically. It's not needed now, but it may be useful to have if I'll want to scale-up.

I'm still unsure if I should do it. Here I will gather all pros and cons of such change.

Pros:

It will be possible to allocate TTD on a heap (right now it will be always in .bss)
Erasing data will be simpler. If DMAPI is used than just ttd = NULL is good enough.

Cons:

A time consuming task that has zero immediate value
Pointer de-reference instead of a direct jump for each access to TTD value.
Trusted layer should guarantee immutability of a pointer for a duration of transaction

Also, the general idea is that nexoid-ed project should be as small as possible. It should be able to run on most restricted embedded systems. Maybe, it would be nice to be able to run using deterministic amount of memory.

Implement proper BCD arithmetics

Write tests and implement BCD arithmetic. It's needed eg. in procedure Check_Payment_Amounts or Match_Prefix

UT ut/nexoid-ut-x86_64.t:118:F:utils:yymmdd_years_differ fails

Test fails

./ut/nexoid
Running suite(s): tag_retrival
 utils
95%: Checks: 23, Failures: 1, Errors: 0
ut/nexoid-ut-x86_64.t:118:F:utils:yymmdd_years_differ:0: Assertion 'yymmdd_cmp(b, a) == -1' failed: yymmdd_cmp(b, a) == 0, -1 == -1
make: *** [Makefile:168: test] Error 1

Function yymmdd_cmp isn't implemented correctly

Implement "Save Transaction for Receipt Copy"

As defined int nexo-FAST v.3.2 note 68-20

Remove old global variables like g_callTms or g_CandidateList

Refactoring is needed

Replace "Authorise Service" with "Data Interaction"

Service authorisation is out of scope of nexo-FAST, but I think it's a sensible idea to move it to "Data Entry Interaction" and it should set bool securityPermission variable.

Moreover function scap_Authorise_Service is deprecated for very long time.