DarwinX - The Target of Evaluation, and where it ends

NACEF · cahier des charges v1.2 · read for auditors

73 requirements outside the perimeter, 34 inside: NACEF read by its own boundary

A Target of Evaluation is the product, system or component that is the subject of a security evaluation under the Common Criteria framework. The word carrying the weight is subject: not the system, but the part of it someone agreed to examine. NACEF designates it precisely as the E-MDF and its cryptographic key support. The cash register is outside. And the specification is itself split along that line, which is the cleanest thing in the document and the least discussed.

CE caisse enregistreuse S-MDF client signs tickets for the till software S-MDF agent also designated SIC E-MDF module de facturation SAM secure access module IMDF module identifier

1 · the boundary

Inside the evaluated perimeter, and outside it

Two transmission hops carry the whole system. The cahier des charges names both under a single confidentiality requirement, and they are not equally well defended in practice.

H0201, verbatim in scope: "Chiffrement des donnees en transit. Objectif : proteger les donnees pendant leur transmission : 1. Entre la caisse et le E-MDF. 2. Entre le E-MDF et [la plateforme]." Hop 2 is over the internet and everybody treats it as hostile. Hop 1 sits on the merchant's own machine, and that is the one that gets left in the clear.

1b · the schema, whole

The document is split by the boundary it draws

This is not an interpretation. Count the requirement codes: 73 in the E series, governing the cash register and its software, and 34 in the H series, governing the module and its protection profile. The E series never reaches inside the perimeter. The H series never reaches outside it. Once you see it, the whole scheme reads differently.

E series · 73 requirements · OUTSIDE the TOE

The caisse and its software

`E01`	General conventions, operating principle
`E02`	Sales recording, the ticket, access management
`E03`	Parameterisation and configuration
`E04`	Operation traceability, the installers
`E05`	Data recording, software traceability
`E06`	Data security and integrity, maintenance
`E07`	Cloture
`E08`	JSON object formats
`E09`	Traceability of every event, offline mode included
`E10-E12`	Versions, counters, regulatory requirements
`E13`	Archival - open format, timestamped, one year or one exercise
`E14-E15`	Purge, data conservation, capacity supervision
`E16-E17`	Backup / restore, documentation

H series · 34 requirements · INSIDE the TOE

The module and its protection profile

`H01`	Logical components; signature online and offline; post-offline synchronisation; audit over removable media; encrypted local storage
`H02`	Protection profile - confidentiality in transit, integrity, parameter storage, modification journalling, rollback, authentication, authorisation, key rotation, symmetric and asymmetric crypto, firewall, connectivity control
`H03`	QR codes, ONLINE and OFFLINE variants
`H04-H08`	Hardware requirements, module types, the Server variant, agents, installers

Every requirement an evaluator would test lives in this column. It is the shorter one.

The asymmetry is the finding. Two thirds of the text governs the component that is explicitly not the subject of the evaluation. That is not a flaw: a cash register needs rules whether or not anyone evaluates it. But it means a reader who does not know the boundary will spend most of their attention outside it, and will finish the document believing the security case has been made in far more detail than it has.

1c · why it is not in production yet

The evaluation is deferred, and that is a defensible order

The protection profile is written. No taxpayer is behind an evaluated module today, and it is worth being precise about why, because "nobody bothered" is both unfair and wrong.

The transaction comes first

Before anything can be evaluated there has to be something to evaluate: identifiers issued, tickets signed, modes working, synchronisation closing. A scheme that cannot record a sale correctly gains nothing from a hardened module.

Then manipulation

The failures that cost the treasury most are under-declaration and unrecorded sales, and neither is addressed by evaluating the module - they are addressed by reconciliation. Putting that capability first is the correct use of scarce attention.

Then the programme has to exist at all

Editors homologated, installers trained, merchants equipped, a support chain that answers on a Saturday. An evaluation regime with no fleet to apply it to is a document.

So the honest statement is not that Tunisia skipped the security half. It is that the security half is written and not yet exercised, while the effort goes where the revenue is, which is transactions and manipulation. The risk in that order is only that "deferred" quietly becomes "assumed": every year the fleet grows, the cost of introducing an evaluation regime grows with it, and the requirements in the H column go on being declared by the parties that implement them.

2 · what the TOE must do

Functional requirements, and the protection profile

Ref	Requirement	What an auditor actually tests
`H0101`	Functional modules: electronic signature, business module for QR generation, and the rest	Are they separable, or is "the module" the whole POS with a signing call inside it?
`H0104`	Signature in online mode: obtain the unique id, sign, hand the signed ticket to the platform immediately	Does it fail closed when the platform is unreachable, or fall back silently?
`H0105`	Signature in offline mode: use a unique id from the last batch retrieved	What happens when the batch is exhausted mid-service?
`H0106`	Synchronisation after offline use: authenticate, transmit everything recorded offline, record what comes back	Is the offline set transmitted completely, or best-effort?
`H0107`	Audit: removable media on USB, verify signature and syntax of the request file, run the procedure, encrypt the report, write it back	Does it verify the request signature before executing, or after?
`H0108`	Local storage support plus an encryption mechanism for stored data	Where does the encryption key live, and what reads it?
`H0201`	Encryption in transit, caisse to E-MDF and E-MDF to platform	Hop 1. Plain HTTP on loopback is a finding, not a detail.
`H0203`	Integrity of stored and transmitted data, with a detection mechanism	Detection of what, by whom, reported where?
`H0204`	Secure storage of parameters; the module must forbid unauthorised change	Can a local admin edit a parameter file and have it honoured?
`H0205`	Journalling of every modification to locally stored data; rollback mechanisms	Is the journal itself protected from the rollback?
`H0206`	Authentication of E-MDF users; security of the taxpayer signature key	Who can invoke a signature, and how is that identity established?
`H0207`	Granular authorisation by role; rotation of all software keys, session keys included	Rotation on what trigger, and what happens to tickets signed under the old key?
`H0208`	Symmetric encryption; firewall controlling open ports	Which ports does the E-MDF open, and to which interface is each bound?
`H0209`	Asymmetric encryption per current regulation; internet connectivity control, Wi-Fi included	Is the till on the same Wi-Fi as the guest network?

Requirement references and objectives read from the published cahier des charges, NACEF v1.2. Test columns are mine.

3 · the ticket, controlled locally

Two modes, two QR codes, one identity

Every ticket carries a unique identifier issued by the platform. Online, the module obtains it and returns the signed ticket immediately. Offline, it consumes an identifier from a batch retrieved earlier. The first line of the QR code declares which happened, so the mode is not an internal detail: it is printed on the customer's receipt.

QR, mode ONLINE
-----------------
line 1  ONLINE
line 2  ticket identity
        transaction type
        total HT
        total ...

QR, mode OFFLINE
-----------------
line 1  OFFLINE
line 2  ticket identity
        transaction type
        total HT
        total ...

This is the strongest control in the whole scheme and it costs nothing. An inspector holding a receipt can see, without any system access, whether that sale was signed against a live identifier or against a pre-allocated batch. A merchant permanently offline prints it on every receipt they hand out.

4 · the offline bound is in the specification

Three days, or the batch runs out

The scheme already bounds disconnected operation. A module leaves usable state when synchronisation has not happened for three days, when the maximum number of tickets signed while disconnected is reached, or when it detects incoherent data. The manifest carries availableOfflineTickets, so the remaining budget is a number the module holds and can be asked for.

Correcting myself. An earlier version of this page presented the offline horizon as a design proposal. It is not: it is in the cahier des charges. The open question was never whether the bound exists. It is whether an implementation enforces it, and that is an evaluation question, not a specification question.

Days since last synclimit is 3

Batch sizeavailableOfflineTickets at sync

Tickets per dayone till

Bound enforced?1 yes, 0 no

Within the bound

tickets covered by spec

Beyond the bound

signed past 3 days or past batch

Binding constraint

which limit hits first

Batch exhausted on day

at this volume

5 · where it breaks

The signature proves integrity after the caisse. It cannot prove the sale.

This is the boundary drawn in section 1, stated as its consequence. The TOE is the E-MDF and its key. The caisse is outside it. The amounts, the lines, the transaction type all arrive from outside, and the module signs what it is handed.

Hop 1 in the clear

H0201 requires encryption between the caisse and the module. It is loopback, so it feels internal and gets shipped as plain HTTP. Anything running as any local user can then reach the signing endpoint directly, or sit between the two and alter what is signed.

Open ports, unbound

H0208 asks for firewall control of open ports. A module listening on 0.0.0.0 rather than the loopback interface is reachable from the shop Wi-Fi, which H0209 also raises. Same finding, two requirements.

Under-declaration is invisible

A sale rung at a third of its value produces a perfectly valid signature over a truthful record of a false amount. No cryptography detects this, and no audit of the module will find it. It is detectable only by comparing the module against something that saw the real sale.

That third point is not a criticism of the scheme, it is the honest scope of any fiscal module, and stating it plainly is what separates an evaluation from a sales sheet. The signature guarantees that what the caisse declared has not been altered since, that it is attributable to a taxpayer key, and that it is anchored to an identifier the platform issued. Those are strong, useful properties. None of them is a claim about what the customer actually paid.

6 · the gap

Homologation is not evaluation

The specification designates a Target of Evaluation and lists a Protection Profile. Those are the vocabulary of a security evaluation: a defined perimeter, stated security objectives, and an independent assessment that the objectives are met against an attacker with stated capability.

what exists

Functional homologation

A dossier, test scenarios, a passage before the instance. It establishes that the software calls the right services, in the right order, and produces conformant output. It is real work and it is necessary.

what the text asks for

A protection profile

H0201 to H0209 are security objectives: confidentiality, integrity, authentication, authorisation, key rotation, logging, vulnerability analysis, network control. Objectives are not tests. They become tests only when someone is mandated to try to defeat them.

what is missing

The evaluation itself

No lab, no assurance level, no attacker model, no independent verdict on the TOE. Which means the security half is declared by the same party that built it, and the strongest requirements in the document are the least verified.

Everything above is readable from the published specification. Nothing here reports a finding against any named product, and no implementation was tested to produce this page. The purpose is to make the perimeter and its consequences legible, so that a conformity conversation can start from the boundary rather than arrive at it by accident.