Page tree
Skip to end of metadata
Go to start of metadata

1. Vision of the software will be developed (purpose of the project)

The Evidence Emitter Architectural Building Block enables National Contact points to generate and emit electronic evidence used for non-repudiation purposes, based on each domain respective regulations and technological need.

Harmonizing the non-repudiation requirements for all the different e-SENS domains is a challenging task. Every domain has a vertical specialization (both from a technical and from a regulatory standpoint) with respect of the non-repudiation services. The White Paper on Non Repudiation Services[1][2]  highlighted a path towards a common set of cross-border and cross-sector interoperable non-repudiation services using a per-hop (e.g., per-corner) evidence-based mechanism. The mechanism allows for a generic, horizontal, and legally stable technology used to emit and store evidence guaranteeing both interoperability and the per-domain specific needs.

The core of the abovementioned mechanism is the Evidence Emitter ABB, which can run in any corner of the e-SENS model. By inspecting the incoming (or outgoing) message, it provides a mechanism to guess the application domain (e.g., eProcurement, eHealth, eJustice) and triggers the emission of the specific set of evidence, by evaluating a previously agreed security policy. The expected set of evidence emitted is the domain-specific one (e.g., IHE ATNA) and the generic, interoperable one (e.g., ETSI REM) and it may be signed according to the domain needs.

For the detailed discussion of the non-repudiation aspects in the 4-corner model, please refer to [1].

The current epSOS specifications tackle non repudiation aspects in [3] by further specifying the the audit trails. However these recommendations are not inlined with the ISO 13888 standard neither with the ETSI REM standard, which is selected as the target architecture for the eDelivery CEF building block.

The non-repudiation framework proposed by e-SENS aims at providing a cross-sector technology that selects and feeds the correct evidence emitter for the specific domain. For instance, by the usage of a policy evaluation outcome, the obligations contain the necessary data to be used to feed the audit trail emitter in parallel with the ETSI REM. The Non Repudiation implementation is an instance of the well known Message Inspector and Secure Session Façade Core Security Patterns.

[3] See e.g., epSOS D3.4.2, Section 4.5.6 Audit Trail Data for Non-Repudiation


2. Stakeholders (role description)

  • Health Professional: information system/information service user;
  • Patient: service beneficiary; 
  • National Authority: national responsible for the eHealth National Contact Point;
  • Data Controller: responsible for and must put in place processing contracts with their 'data processors'. 
  • Data Processor: actor processing personal data in a specific context and with regard to specific sets of data or operations.

3. Users (need of each user)

Why non-repudiation is needed? When NCPs exchange messages, they should produce enough evidence for further investigation in case of disputes. Here are some examples of the cases when this might be needed:

  1. In ePrescription, the patient returns to the home country and claims reimbursement of 3 packages of the drug purchased abroad. The dispensation only shows that 1 package was dispensed. The organization of NCP A now needs to prove that erroneous information was received from NCP B and was not generated while processing the dispensation information in the NCP or NI software. A similar case arises when the patient claims they only purchased 1 package out of 3, and there should be still some available amount on the prescription. The NCP A needs to show that the information received from NCP B was wrong.
  2. In Patient Summary, a drug is administered to the patient, and the patient suffers a severe allergic reaction. The allergy to the drug was mentioned on the patient summary, but the doctor claims that this information was not delivered and shown to them. Now NCP B wants to demonstrate that this information was indeed not received from Country A.

In these cases, the contents of the documents exchanged by the NCPs should be available for later examination during dispute resolution.


4. Features that will be developed (from here we will create jira issues)

  • When in the workflow there is the need to send an audit trail, instead of directly calling the method that creates the audit, the framework is invoked, by passing the message and the context (e.g., TLS, datetime) as parameters. The framework decides which evidence emitter to trigger

5. Features that will NOT be developed (very important in order to be easily found what decided not to be developed for further reference)

 

 

 

 

 

 

Action Items:

  • person - task -date

10 Comments

  1. Konstantin Hyppönen

    Thank you Masi!

     

    As I am very new to e-Sens, could I ask you for a very short description of what is the main problem that this code solves? How does it affect the ePrescription or Patient Summary use case, and how to plug it in an NCP? Sorry if these questions sound stupid. Perhaps you could participate to one of the OpenNCP meetings so that we could interrogate you J

     

    I always thought that the main two non-repudiation issues in epSOS are:

    [if !supportLists]1)      [endif]Prove that the patient was really at the PoC if she claims afterwards her data were read without permission.

    [if !supportLists]2)      [endif]Prove that the transformation manager performed transformations correctly (it does not write a decent audit log).

    What of these are addressed, or perhaps it is something else?

     

    What is the licence of the code uploaded to BitBucket? It would be nice to have licence references in the headers of the source files.

    1. Dear Konstantin, 

      Happy to hear from you! (smile) I hope everything is fine!!!! 

      Shortly: ISO13888 defines a difference between Audit Trails and Non Repudiation. In fact, non repudiation is a fairly complex matter which includes not only the "evidence" (somehow mimicked by our Audit Trails) but also a set of algorithms that enables an actor (software or human) to solve automatically or manually the disputes. 

      Non Repudiation tokens strongly depends on the message exchange pattern. Ideally four non repudiation tokens are identified: Non Repudiation of Origin (NRO), of Receipt (NRR), of Delivery (NRD), and of Submission (NRS). 

      The e-SENS project aims at harmonizing various sectors (including but not limited to eHealth, eJustice, eTendering, etc.) by providing building blocks that each pilot can re-use. Such building blocks aims at enhancing the use cases coming from the LSPs. The definition of "enhancing" depends on the pilot plans and the MS wishes.

      For our domain the plans include a way to "fill the gaps" left open by epSOS (such as certificate relaxations, central configuration services, electronic identification) and, Non Repudiation. Following the aim of the project, we aim at providing a path towards an interoperable non repudiation tokens: a set of evidence and a protocol that is the same amongst all the sectors. The target architecture chosen by the commission is ETSI REM. Although this standard is made having eMail exchange in mind, it is extensible and will be further extended by ETSI to include the whole eDelivery concept. 

      Thus, this simple non repudiation framework defines a legally stable mechanism (implemented as a XACML policy following our ESS scenario) to decide which, and how many, NR* tokens to issue. 

      It is an instance of the Secure Session Facade and the Message Inspector patterns (from java Core Security Patterns). 

      The e-SENS project works as follows: WP6 produces Generic Implementations, which must be customized by WP5. The implementation is the generic one, from WP6, and it shall now be customized (e.g., to add the inspectors for the 5 epSOS messages).

       

      The license is EUPL AFAIK ...

       

      Was I clear enough? 

       

      1. Thank you Massi!

         

        EUPL is something that we did not have in our arsenal, let's add it to the list (smile)

        ISO13888 says that "The goal of the non-repudiation service is to generate, collect, maintain, make available and validate evidence concerning a claimed event or action in order to resolve disputes about the occurrence or non-occurrence of the event or action.". Part of this is, as you note, solved by audit logging, but of course not all. In any case, I am interested to figure out what are these disputes potentially occurring in eHealth scenarios, such that they cannot be solved by audit logging, and require more robust non-repudiation solutions.

        1. Konstantin, 

          e-SENS didn't decide yet for the license at the moment. Sören keeps saying that EUPL may not be the correct one, while GNU.org strongly suggest to use the APLv2. I am open to suggestions. 

          I am not also a lawyer, but if you want to know more about the legal issues and how to achieve interoperability on cross-sector evidence, I can point you to the legal guys. 

          The idea of the framework is not to replace the Audits, not at all (although we may think to rewrite them to the DICOM schema, since the rfc3881 has been removed by IHE). The idea of the framework is to decide which evidence to send, based on the content of the message. Is it an XCA message? Yes, then send the ATNA audit. Is it an eProcurement? Then send an eProcurement evidence. The commission's target architecture is to go to ETSI REM, and this is the reason why there is the plan to couple REM with ATNA. 

          (smile)

  2. by Konstantin Hyppönen

    Dear all,

    As we discussed on Thursday, we need to store signatures of the messages (or only documents included in the messages) exchanged by NCPs.

    Today in the testing meeting Marcello raised the point that NCPs cannot store documents due to legal issues. This is the responsibility of the national infrastructures.

    I understood that basically this would mean that every NCP will
    - Apply signatures on the outgoing messages
    - Verify signatures of the incoming messages
    - Store signatures and some other new data on the audit log
    - On the NCP A side, national connector or NI will store all messages or documents exchanged by the NCP
    - On the NCP B side, Portal B or another national connector or NI will store all messages or documents exchanged by the NCP

    Everything is based on a combination of 5 different standards (IHE ATNA, ISO 13888, ETSI REM, W3C XML DSig, OASIS XACML) created by 5 different SDOs. I would assume it will take some time to learn the details of the standards, to implement and to test, despite the partial implementation kindly provided by Massi.

    Konstantin Hyppönen, PhD
    Senior IT Specialist
    Kela (The Social Insurance Institution of Finland), Kanta Services Unit
    P.O.B. 371, 40101 Jyväskylä
    Tel. +358 50 5516096, +358 20 6345484
    www.kanta.fi/en
    www.kela.fi/web/en

    1. by Stéphane Spahni


      Hello Konstantin,

       

      Thanks for the summary - it it clear and precise...

      I agree with you for what it would mean. 

      One question regarding the 5 standards: are you also saying that NC/NI will have to implement those or just that they have to be able to answer to some jurist's request ?

      In the first case, this will certainly take an even longer time and possibly imply new national regulations...

       

      Kind regards,

       

      Stéphane

    2. Konstantin, 

      Let me stress again that the implementation that I provided is for a non repudiation protocol not, for a set of evidence content, which is exactly what has to be profiled together with ETSI, OpenNCP, and EXPAND. The content of the evidence is out of scope of e-SENS. (smile)

      Having said that, let's talk about serious things. I don't know yet how if, and how many resources I have in EXPAND, but this discussion it is extremely relevant. Before committing on storing body information somewhere, I strongly encourage you to read or scan the various Zhou models provided in the white paper, to see to what extent we would like to achieve non repudiation. Specially, the Arne Tauber's paper provide a very interesting survey that can be used as a basis.

      If we have limitations on storing bodies on the NCP (the target of the non repudiation) then we may require different properties of the protocol (e.g., weak fairness), and still have an acceptable non repudiation mechanism.

      Moreover formal analysis proved that non repudiation fair protocols have to be carefully designed to avoid token forgery and token suppression. Such formal analysis always assume a DolevYao model. I suggest as starting point to provide a mapping with the NRO and NRR tokens format defined by the ISO 13888 and see which data is available at the NCP level. I also assume that we agree on just having these two tokens (what about NRS and NRD?).

      In fact, storing non repudiation data outside the NCP, protecting NCP to NCP communication is something which has to be evaluated, from a risk analysis standpoint: can it be attacked? How the disputes are solved?

  3. Massi, can you please send me the papers by Zhou and Tauber? I cannot access ScienceDirect or Springer, as we are not a research organization. I could only access Tauber's PhD thesis, which is of course interesting.

    An excerpt from it: "Due to this gap, the research community has provided many protocols for secure messaging over the last two decades. They have been published as fair non-repudiation protocols. The aim was to design security extensions for asynchronous communications providing similar added value as traditional registered or certified mail do in the postal world."

    In epSOS, we have synchronous communication. What is the impact of this fact? 

    1. Following you guys... Massimiliano Masi any docs you could share here?

      Konstantin Hyppönen, about Tauber's PhD , any chance you can link it here?