• Created by Unknown User (servaasschramaadmin) on Dec 01, 2023

End-to-end encryption is applied in Elektronische Toegangsdiensten to protect privacy of anyone (acting users) or organisations (especially "single person businesses" or "eenmanszaak"). The BSN is one of the main privacy concerns, following from Dutch law, but other personally identifiable information must also be protected. Using end-to-end encryption as described on this page avoids an Herkenningsmakelaar (HM) becoming an unintended hotspot for information on service usage.

Introduction

Personally Identifiable Information (PII) forms the basis of authentication and authorisation (mandates). PII can lead to identification of the particular person, either through the data itself (identifiers), or by combining data, leading to recognising the person through patterns in that data. Within eTD, PII is dispersed over various registers, operated by various participants. During the authentication and authorisation processes this data must be combined using assertions that are strongly linked together, in order to firmly establish involved identities and appropriate mandates that can be trusted by service providers in order to securely provide requested services.

Usage of this sensitive data implies that both "security" and "privacy" are important. Security refers to confidentiality, integrity (among which authenticity) and availability of the information. Privacy aims that the user is always in control of his/her data, and can trust that only parties for which (s)he gave consent for, have access to that data.

In order to protect PII during this process, several measures are taken, jointly called "end-to-end encryption", that are intended to:

  • allows only the intended recipients to see data as needed to perform the required service (principle of "least privilege"); this applies to eTD-participants as well as service providers
  • prevent "hotspots" to attack; within eTD this applies especially to the HM, since all information is routed through the HM.

Overview of protection measures

The data that must be protected, is categorised as:

  • identifiers (BSN, pseudonyms, KvK-nrs, etc)
  • content/attributes (name, address, date of birth, etc)

Both categories contain data that is considered sensitive, but the measures to protect them, while partly overlapping, are also partly different.

Basic measures that apply to both categories, are:

  • Sensitive data is encrypted for the intended recipient using XML-based encryption to provide confidentiality

    • for "content" the only valid recipient is the DV (for "identifiers", see below)
      note that for Service Intermediation (dienstbemiddeling) it is important to distinguish between the "dienstbemiddelaar" (DB, Service Broker) and "dienstaanbieder" (DA, service provider); each has its own entry/service in the Service Catalog, and the data must be encrypted for the appropriate party that provides that particular service.

  • Assertions are digitally signed to provide proof of integrity/authenticity
  • Key management is regulated to provide appropriate availability

For "content" these basic measures are deemed sufficient.

For "identifiers", on top of these basic measures, some additional measures were taken, because:

  • some identifiers (especially BSN) are determined as extra sensitive in Dutch law
  • identifiers are more easily recognised by hackers, and allow for easy correlation of related data
  • identifiers are sometimes relevant to multiple relying parties (recipients; e.g. DV, MR) and must therefore be encrypted separately for each recipient

The additional measures for identifiers are:

  • Pseudonymisation:
    • Using separate pseudonyms for the user per "relying party" whenever this is sufficient (i.e. no formal identifier like "BSN" needed)
    • These pseudonyms are persistent per "relying party", so it can recognise "returning users"
    • These pseudonyms are different across "relying parties", so users cannot be traced across "relying parties".
  • Encryption of identifiers
    • All identifiers (including the pseudonyms) are encrypted during transfer in each assertion
    • The "encrypted value" is different during each "transfer", so in-between parties (e.g. HM) cannot relate various "transfers" of the same identifier
    • For identifiers and pseudonyms based on the "BSN", and the "eIDAS Uniqueness Identifier", polymorphic encryption is used
      • In the future, polymorphic encryption could also be used for other identifier types

Note that using the BSN for polymorphic encryption, requires "activation" of the BSN at BSNk. BSNk only allows this activation if a minimum authentication of LoA3 (substantial) is provided.

Impact on interfaces

The measures described above are applied in different ways, depending on the situation. The relevant situations are detemined by aspects like:

  • "is the acting person acting for him/herself (no representation), or someone else (representation of person or organisation)",
  • "is the BSN required or not",
  • "is the BSN known by the eTD-participant or not", and
  • "what version of the interfaces are supported by the Service Provider".

Normal "content" is only intended for the Service Provider (and not for any of the eTD-participants). This means that when this data is deemed sensitive, it is always XML-encrypted with the public key of the Service Provider, as provided in the Service Catalog. Therefore only the Service Provider can access this data.

For "identifiers", the sections below apply.

No representation

The situation of "no representation" means that:

  • the acting subject ("handelende persoon") acts for him-/herself
  • the legal subject ("belanghebbende") is the same person as the acting person

This implies that no specific "mandate" is required, and the MR is not involved. So, next to the Service Provider, only the AD and HM are involved

In principle individuals can also have restrictions regarding authorisations on services for themselves, like when the person is "minor", "deemed not to be capable of taking responsibility", etc. So even when currently, "mandates" are not required for "non-representation", this may change over time.

Depending on the required service (as specified in the Service Catalog), 2 main scenarios, requiring different measures, apply to this:

  1. BSN is required by the service, or
  2. a pseudonym suffices for this service

BSN required

A service is requested for which the service provider requires a BSN as identifier for the acting person, as specified in the Service Catalog. The service provider must be authorised to receive a BSN for this particular service. This means that the service must be authorised on the "Autorisatielijst BSN".

The main consequences are:

  1. The BSN of the acting subject must be activated with BSNk by the AD, during onboarding, resulting in a Polymorphic Identity (PI), which is managed by the AD

  2. The AD transforms the PI into an Encrypted Identity (EI, or "Versleutelde Identiteit": VI), encrypted for the Service Provider, which is the only relying party in this scenario

  3. The AD adds the EI to the AD-assertion and returns this in its response to the HM

  4. The HM adds all relevant "identifiers" and "content" in its response to the Service Provider

  5. The DV decrypts the EI to a BSN.

Pseudonym required

A service is requested that requires a pseudonym for the acting person (not a BSN), as specified in the Service Catalog. For this situation, 2 different scenarios are possible, depending if the user has on-boarded at his/her MU/AD with BSN or not.

  • In case (s)he did NOT onboard with BSN, the AD must produce a so-called Specific pseudonym (SP), which is usually related to the "means of authentication", and not to the BSN.
  • Otherwise, the AD has activated the BSN at BSNk and received a Polymorphic Pseudonym (PP), and could work with this.

Currently, the default pseudonym is the Specific Pseudonym. Only in case of eIDAS Outbound, the Polymorphic Pseudonym is used. In the latter case, this is explicitly specified in the Service Catalog.
When the "Wet Digitale Overheid" (WDO) comes into force, this may need to change. At that time further guidelines must be determined when to use which type of pseudonym.

In case the Specific Pseudonym is required:

  1. The AD provides an encrypted Specific pseudonym of the user for the DV to the HM, encrypted to the DV
  2. The HM can provide the encrypted pseudonym in its response to the DV, without being able to access the value of the pseudonym nor being able to trace users across DV's
  3. The DV can decrypt the pseudonym and use it as an identifier to the account of the user for its business processes.

In case the Polymorphic Pseudonym is required:

  • The BSN of the acting subject must be activated with BSNk by the AD, during on-boarding, resulting in a Polymorphic Identity (PI), which is managed by the AD

  • The AD transforms the PP into an Encrypted Pseudonym (EP, or "Versleuteld Pseudoniem": VP), encrypted for the Service Provider

  • The AD adds the EP to the AD-assertion and returns this in its response to the HM

  • The HM adds all relevant "identifiers" in its response to the Service Provider

  • The DV decrypts the EP to a PP and uses this as identification of the user.

Representation

Currently only representation of organisations is supported. In the future, also representation of individuals may be supported. This is an overview of the different options:

  1. An employee (or other contracted person) performs services for an organisation (supported)
  2. Organisation A performs services for organisation B, executed by a person working for organisation A: "Ketenmachtiging" or "chain authorisation" (supported)
  3. Organisation performs service for individual consumer (not supported yet; requires co-operation with other schemes)
  4. Individual performs service for another individual (not supported yet; requires co-operation with other schemes)

Option 1 and 2 are described further. Option 3 and 4 are out-of-scope, and may be added later.

Employee / contractor for organisation (single authorization)

  1. The AD provides to the HM:
    1. an encrypted Internal pseudonym of the user for the MR, as EncryptedID, encrypted to the MR
    2. any identifiers as specified in the ActingSubjectTypesAllowed in the appropriate service in the service catalog, as EncryptedID, encrypted to the DV
  2. The HM
    1. forwards this in the request to the MR
    2. is not able to access the value of the EncryptedIDs and is not able to trace recurring users.
  3. The MR
    1. decrypts the pseudonym from the HM request.
    2. selects the appropriate user authorization
    3. provides EncryptedID's (encrypted to the DV that delivers the service) containing
      1. the Specific pseudonym of the user to the HM, and
      2. any identifiers of the represented entity as specified in the EntityConcernedTypesAllowed in the service definition
  4. The HM provides the EntityConcernedTypes and the specific pseudonym of the acting user for the DV in its response to the DV.
  5. The DV can use the EntityConcernedTypes and the specific pseudonym of the user for its business processes.

Organisation to organisation (chain authorisation)

  1. The AD provides to the HM:
    1. an encrypted Internal pseudonym of the user for the MR, as EncryptedID, encrypted to the MR
    2. any identifiers as specified in the ActingSubjectTypesAllowed in the appropriate service in the service catalog, as EncryptedIDs, encrypted to the DV
  2. The HM
    1. forwards this in the request to the MR of the user (MR1)
    2. is not able to access the value of the pseudonym and is not able to trace recurring users.
  3. MR1
    1. decrypts the pseudonym from the HM request
    2. selects the user authorization for organisation A (Intermediary organisation).
    3. allows the user to choose the ultimate represented party (organisation B)
    4. provides a response to the HM with:
      1. the Specific pseudonym of the user to the HM as EncryptedID, encrypted to the DV
      2. the standard identifier of the organisation A (intermediary organisation) as EncryptedID, encrypted to MR2 and DV
      3. an "obligation" with the following data related to the ultimate "represented party"
        1. the "default identifier" (currently KvK-nr), as EncryptedID, encrypted to MR2
        2. the "identity of the expected mandates register".
  4. The HM
    1. forwards this information in a request to the MR of the represented party (MR2)
    2. is not able to access the value of the pseudonym and is not able to trace recurring users.
  5. MR2
    1. decrypts the EncryptedIDs (encrypted to MR2) for the intermediary organisation (A) and represented organisation (B);
    2. selects the appropriate authorization of intermediary organisation (A) for represented organisation (B);
    3. provides a response to the HM with any identifiers of the "represented entity" as specified in the EntityConcernedTypesAllowed in the service definition as EncryptedIDs, encrypted to the DV.
  6. The HM provides in its response to the DV
    1. the EncryptedIDs (encrypted to the DV) of organisation A and B and
    2. the EncryptedIDs (encrypted to the DV) of the acting user
  7. The DV decrypts the EncryptedID's of both organisations and the user as it sees fit, and uses them for its business processes.
  • No labels