# Polymorphic Pseudonymization Notation

Polymorfe encryptie en pseudonimisering, uses scheme wide keys. To facilitate key management procedures, all scheme-wide keys are versioned using schemeKeySetVersion. For the BSNk documentation you can contact Logius.

This paragraph describes the technical format of polymorphic identities and pseudonyms and related key formats.

Polymorphic identities and pseudonyms in the scheme are based on cryptographic properties of elliptic curves.

#### Usages of Polymorphic Pseudonymization

- Activation
- Polymorphic Identity or Pseudonym
- Encrypted Identity or Pseudonym

- Usage (transformation and decryption)
- Encrypted Identity or Pseudonym
- Identity or Pseudonym

#### Format for Polymorphic Identity or Pseudonym

A Polymorphic Identity or Pseudonym is a combination of points on an elliptic curve. In order for the Identity or Pseudonym to be properly usable in the scheme, some additional information is needed. This information is necessary for practical management and secure implementation of Identity or Pseudonym in the Scheme and consists of elements like versioning (for key management) and recipient. The syntax for expressing an Identity or Pseudonym with this information is listed below.

Values of the notations below SHALL be represented as (the base64 encoding of) the DER-encoded structure in ASN.1 notation.

##### Polymorphic Identity or Pseudonym

A Polymorphic Identity or Pseudonym consists of 3 points on an elliptic curve. Polymorphic Identity or Pseudonym are provided via the beheerorganisatie BSNk. They are used via the interface spec BSNk: transform. The notation for a complete Polymorphic Identity or Pseudonym is as follows:

Polymorphic Identity or Pseudonym ASN.1 notation

```
PolymorphicIdentity ::= SEQUENCE {
notationIdentifier OBJECT IDENTIFIER (id-BSNk-polymorphic-identity),
schemeVersion INTEGER,
schemeKeySetVersion INTEGER,
creator IA5String,
recipient IA5String,
recipientKeySetVersion INTEGER,
points SEQUENCE (SIZE (3)) OF ECPoint
}
PolymorphicPseudonym ::= SEQUENCE {
notationIdentifier OBJECT IDENTIFIER (id-BSNk-polymorphic-pseudonym),
schemeVersion INTEGER,
schemeKeySetVersion INTEGER,
creator IA5String,
recipient IA5String,
recipientKeySetVersion INTEGER,
type INTEGER,
points SEQUENCE (SIZE (3)) OF ECPoint
}
```

Herein the schemeVersion indicates the version of the cryptographic scheme and this syntax and SHALL start at 1. The schemeKeySetVersion is a version that SHALL start at 1 and represents the effective set of long term scheme master keys (PP-M, PD-M, etc...). The schemeVersion defines the elliptic curve used in the scheme as well. The creator SHALL contain the entityID (OIN) of the creator, and the recipient SHALL contain the entityID (OIN) of the recipient. The recipientKeySetVersion holds the version number for the set of recipient's keys for Polymorphic Identities and Pseudonyms (PA-Di). Note: In schemeVersion 1 the recipientKeySetVersion for MUs and ADs is a sequence starting at 1. Type defines the identity type the Pseudonym is derived of, e.g. from a BSN or an eIDAS Uniqueness Identifier. This field is not necessary in identity based forms as here the identity type will become clear as part of decryption of the final structure, i.e. the Encrypted Identity. The values currently defined are the ASCII value of 'B' (0x42) for BSN based and 'E' (0x45) when based on a eIDAS uniqueness identifier. ECPoint is identical to ECPoint as defined in BSI TR 03111 and ANSI X9.62 (2005). Here two encodings are specified, compressed and compressed. Both encodings are allowed, with a preference for uncompressed encoding.

A Polymorphic Identity of Polymorphic Pseudonym can be signed for integrity protection:

```
SignedPolymorphicIdentity ::= SEQUENCE {
notationIdentifier OBJECT IDENTIFIER (id-BSNk-polymorphic-identity-signed),
signedPI SEQUENCE {
polymorphicIdentity PolymorphicIdentity,
auditElement OCTET STRING,
signingKeyVersion INTEGER
},
signatureValue ECDSA-Signature
}
SignedPolymorphicPseudonym ::= SEQUENCE {
notationIdentifier OBJECT IDENTIFIER (id-BSNk-polymorphic-pseudonym-signed),
signedPP SEQUENCE {
polymorphicPseudonym PolymorphicPseudonym,
auditElement OCTET STRING,
signingKeyVersion INTEGER
},
signatureValue ECDSA-Signature
}
```

An auditElement holds an audit value consisting of an identifier for the creator, a timestamp and a sequence number from that creator. This auditElement is 16 bytes in big-endian (32-bit origin, 32-bit timestamp and 64-bit sequence-number). The origin identifies the party providing the Polymorphic/Encrypted Identity or Pseudonym and the unique device used. The timestamp and sequence number can be used in case of a compromise or dispute, so that mitigating measure or resolution can be accomplished. Note: the timestamp is 32-bit in seconds since 1 jan 1970 UTC. The auditElement is encrypted under a key only retrievable by the supervisor of the scheme, which is provided to the supervisior by the keymanagement role.

The signatureValue can be used to assert the authenticity of the (polymorphic/encrypted) Identity or Pseudonym. The signature is applied to the byte sequence of the complete DER-encoded signed sequence (e.g. signedPP in a SignedPolymorphicPseudonym). The public key for verification can be retrieved using the creator from the structure covered under the signature and the signingKeyVersion.

```
-- ECPoint is described in ANSI X9.62 (2005), annex E.6.
-- In particular, encoding from point to octet string and
-- from octet string to a point is defined in annex A.5.7
-- and A.5.8 of ANSI X9.62.
ECPoint ::= OCTET STRING
ECDSA-Signature ::= SEQUENCE {
signatureType OBJECT IDENTIFIER (ecdsa-with-SHA384),
signatureValue EC-Sig-Value
}
-- EC-Sig-Value is identitical to BSI TR 03111 ECDSA-Sig-Value.
-- which is identical to ECDSA-Sig-Value defined in RFC5480 as well.
EC-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}
ecdsa-with-SHA384 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4)
ecdsa-with-SHA2(3) 3 }
id-BSNk-scheme-nl OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) nl(528) nederlandse-organisatie(1) nederlandse-overheid(1003) logius-beheer-usve(10) }
id-BSNk-identifiers OBJECT IDENTIFIER ::= { id-BSNk-scheme-nl 1 }
id-BSNk-polymorphics OBJECT IDENTIFIER ::= { id-BSNk-identifiers 1 }
id-BSNk-polymorphic-identity OBJECT IDENTIFIER ::= { id-BSNk-polymorphics 1 }
id-BSNk-polymorphic-pseudonym OBJECT IDENTIFIER ::= { id-BSNk-polymorphics 2 }
id-BSNk-polymorphic-identity-signed OBJECT IDENTIFIER ::= { id-BSNk-polymorphics 3 }
id-BSNk-polymorphic-pseudonym-signed OBJECT IDENTIFIER ::= { id-BSNk-polymorphics 4 }
```

##### PIP – PPCA optimized

For privacy enhanced implementation, Polymorphic Identities and Pseudonyms can be implemented on a smartcard. This is called a PP-card application, or PPCA. A Polymorphic Identity and a Polymorphic Pseudonym can be combined to 5 points on an elliptic curve rather than six, for optimization in a smartcard implementation. The PPCA-optimized PIP version of Polymorphic Identities or Pseudonyms are provided in Interface spec BSNk: activate.

The combined notation for an Polymorphic Identity and Pseudonym is as follows:

Polymorphic Identity and Pseudonym (PIP) ASN.1 notation

```
PIP ::= SEQUENCE {
notationIdentifier OBJECT IDENTIFIER (id-BSNk-polymorphic-pip),
schemeVersion INTEGER,
schemeKeySetVersion INTEGER,
creator IA5String,
recipient IA5String,
recipientKeySetVersion INTEGER,
type INTEGER,
points SEQUENCE (SIZE (5)) OF ECPoint
}
```

The first, second and fourth ECPoint in a PIP correspond to those of a PI. Similarly, the first, third and fifth correspond to those of a PP. In this fashion one can extract a PI and PP from a PIP.

There also exists a signed version of a PIP:

```
SignedPIP::= SEQUENCE {
notationIdentifier OBJECT IDENTIFIER (id-BSNk-polymorphic-pip-signed),
signedPIP SEQUENCE {
pip PIP,
auditElement OCTET STRING,
signingKeyVersion INTEGER
},
signatureValue ECDSA-Signature
}
```

Which follows the same concepts as described for a Polymorphic Identity or Polymorphic Pseudonym.

```
id-BSNk-polymorphic-pip OBJECT IDENTIFIER ::= { id-BSNk-polymorphics 5 }
id-BSNk-polymorphic-pip-signed OBJECT IDENTIFIER ::= { id-BSNk-polymorphics 6 }
-- the following OID is reserved for usage in the specifications of the protocol for PP on smartcard (polymorphic card application)
id-PCA OBJECT IDENTIFIER ::= { id-BSNk-scheme-nl 9 }
```

##### Encrypted Identity or Pseudonym

An Encrypted Identity or Pseudonym consists of 3 points on an elliptic curve. The notation for a complete Encrypted Identity and an Encrypted Pseudonym is as follows:

Encrypted pseudoID ASN.1 notation

```
EncryptedIdentity ::= SEQUENCE {
notationIdentifier OBJECT IDENTIFIER (id-BSNk-encrypted-identity),
schemeVersion INTEGER,
schemeKeySetVersion INTEGER,
creator IA5String,
recipient IA5String,
recipientKeySetVersion INTEGER,
points SEQUENCE (SIZE (3)) OF ECPoint
}
EncryptedPseudonym ::= SEQUENCE {
notationIdentifier OBJECT IDENTIFIER (id-BSNk-encrypted-pseudonym),
schemeVersion INTEGER,
schemeKeySetVersion INTEGER,
creator IA5String,
recipient IA5String,
recipientKeySetVersion INTEGER,
diversifier IA5String OPTIONAL,
type INTEGER,
points SEQUENCE (SIZE (3)) OF ECPoint
}
SignedEncryptedIdentity ::= SEQUENCE {
notationIdentifier OBJECT IDENTIFIER (id-BSNk-encrypted-identity-signed),
signedEI SEQUENCE {
encryptedIdentity EncryptedIdentity,
auditElement OCTET STRING
},
signatureValue EC-Schnorr-Signature
}
SignedEncryptedPseudonym ::= SEQUENCE {
notationIdentifier OBJECT IDENTIFIER (id-BSNk-encrypted-pseudonym-signed),
signedEP SEQUENCE {
encryptedPseudonym EncryptedPseudonym,
auditElement OCTET STRING
},
signatureValue EC-Schnorr-Signature
}
DirectEncryptedPseudonym ::= SEQUENCE {
notationIdentifier OBJECT IDENTIFIER (id-BSNk-encrypted-direct-pseudonym),
schemeVersion INTEGER,
schemeKeySetVersion INTEGER,
creator IA5String,
recipient IA5String,
recipientKeySetVersion INTEGER,
type INTEGER,
points SEQUENCE (SIZE (3)) OF ECPoint
}
SignedDirectEncryptedPseudonym ::= SEQUENCE {
notationIdentifier OBJECT IDENTIFIER (id-BSNk-encrypted-direct-pseudonym-signed),
signedDEP SEQUENCE {
directEncryptedPseudonym DirectEncryptedPseudonym,
auditElement OCTET STRING,
signingKeyVersion INTEGER
},
signatureValue ECDSA-Signature
}
```

The fields correspond to the same fields in a Polymorphic Identity or Pseudonym. The recipientKeySetVersion holds the version number for the set of recipient's keys for Identities and Pseudonyms (PD-Di, PC-Di and PI-Di). Note: In schemeVersion 1 the recipientKeySetVersion for DVs is a value of 8 decimal digits corresponding with the issue date (notBefore) of the certificate, in the format YYYYMMDD, used to request the PEM file at the party generating the keys within the scheme.

A DirectEncryptedPseudonym is – with the exception of the diversifier – identical to an EncryptedPseudonym, although an additonal key and processing step are needed for decryption. The signed form uses a ECDSA instead of a Schnorr signature. This form is (currently) only applicable for reporting from BSNk_registration to CIF.

```
EC-Schnorr-Signature ::= SEQUENCE {
signatureType OBJECT IDENTIFIER (ecschnorr-plain-SHA384),
signatureValue EC-Sig-Value
}
bsi-de OBJECT IDENTIFIER ::= {
itu-t(0) identified-organization(4) etsi(0)
reserved(127) etsi-identified-organization(0) 7
}
id-ecc OBJECT IDENTIFIER ::= { bsi-de algorithms(1) 1 }
ecschnorr-plain-signatures OBJECT IDENTIFIER ::= { id-ecc signatures(4) 3 }
ecschnorr-plain-SHA384 OBJECT IDENTIFIER ::= { ecschnorr-plain-signatures 3 }
```

The auditElement is similar to the auditElement of a Polymorphic Identity or Pseudonym. The signature is a Schnorr signature for efficiency.

```
id-BSNk-encrypted OBJECT IDENTIFIER ::= { id-BSNk-identifiers 2 }
id-BSNk-encrypted-identity OBJECT IDENTIFIER ::= { id-BSNk-encrypted 1 }
id-BSNk-encrypted-pseudonym OBJECT IDENTIFIER ::= { id-BSNk-encrypted 2 }
id-BSNk-encrypted-identity-signed OBJECT IDENTIFIER ::= { id-BSNk-encrypted 3 }
id-BSNk-encrypted-pseudonym-signed OBJECT IDENTIFIER ::= { id-BSNk-encrypted 4 }
id-BSNk-encrypted-direct-pseudonym OBJECT IDENTIFIER ::= { id-BSNk-encrypted 5 }
id-BSNk-encrypted-direct-pseudonym-signed OBJECT IDENTIFIER ::= { id-BSNk-encrypted 6 }
```

##### Identity or Pseudonym

Finally, an Encrypted Identity or Pseudonym can be decrypted into a Identity or Pseudonym respectively, consisting of (the X coordinate of) 1 point on an elliptic curve. The Identity or Pseudonym is not directly used in any of the interfaces, but is the RECOMMENDED representation of a Identity or Pseudonym for a relying party to use after decryption of a Encrypted Identity or Pseudonym.

Decrypted pseudoID ASN.1 notation

```
Identity ::= SEQUENCE {
notationIdentifier OBJECT IDENTIFIER (id-BSNk-decrypted-identifier),
schemeVersion INTEGER,
schemeKeySetVersion INTEGER,
recipient IA5String,
type INTEGER,
identityValue IA5String
}
Pseudonym ::= SEQUENCE {
notationIdentifier OBJECT IDENTIFIER (id-BSNk-decrypted-pseudonym),
schemeVersion INTEGER,
schemeKeySetVersion INTEGER,
recipient IA5String,
recipientKeySetVersion INTEGER,
diversifier IA5String,
type INTEGER,
pseudonymValue IA5String
}
```

In case of an Identity, the identity can be extracted from the X coordinate of the EllipticCurvePoint of the Identity. In schemeVersion 1, the X coordinate, after conversion from a number to a bytearray, contains an encoded identity padded using OAEP as defined in Section 7.1 of RFC8017 (PKCS#1 v2.2). Here the following parameters are chosen:

- The place of n (RSA modulus) is taken by the order of curve q; length in bytes of q is denoted by k as in PKCS #1, i.e. equal to 40 for the Brainpool320r1 curve used in version 1 of the scheme.
- Hash function is SHA384 truncated to first 10 bytes, i.e. hLen = 10.
- Message length mLen = to k – 2hLen – 2 (PKCS #1 only requires ≤), i.e. equal to 18.
- MGF1 as defined in PKCS #1 is used as Mask Generation Function.
- Optional Label is empty string.

The decoded identity (18 bytes) consists of a prefix of three bytes and the identity (e.g. BSN). The prefix consists of a version, a type and a length of the identifier. All not used bytes are zero. That is, 15 bytes is the longest size supported for an identifier in version 1.

In case of a Pseudonym, the identifying, persistent pseudonym of a user is the EllipticCurvePoint of the Pseudonym. The RECOMMENDED representation of a Pseudonym used in a DV registration, consists of the recipientKeySetVersion (decimal string of length 8) of the closing key with the uncompressed EllipticCurvePoint appended. If two such representations are equal the pseudonyms correspond to the same person. However, we can only deduce that two pseudonyms do not correspond to the same person if the pseudonymValue differ while all other values are equal. We note that the recipientKeySetVersion of the closing key can be different from the recipientKeySetVersions of the EI and EP decryption key.

For each decrypted pseudonym the DV shall archive the additional fields decrypted from the Encrypted Pseudonym.

```
id-BSNk-decrypted OBJECT IDENTIFIER ::= { id-BSNk-identifiers 3 }
id-BSNk-decrypted-identifier OBJECT IDENTIFIER ::= { id-BSNk-decrypted 1 }
id-BSNk-decrypted-pseudonym OBJECT IDENTIFIER ::= { id-BSNk-decrypted 2 }
```

##### Key formats

Polymorphic pseudonimization uses various keys. These keys have been versioned, see the syntax above.

Keys for relying parties are provided using the notation described in DV-key format.

Several of the scheme-wide keys are public, and can be used to use the polymorphism or verify signatures. These keys are defined in Metadata and under the role PPSteutelSet in RoleDescriptors non-Participants. For these public keys the brainpool P320r1 curve is used, which is a named curve defined as

```
-- Brainpool curves and the TeleTrust namespace are defined in BSI TR-03111
ecStdCurvesAndGeneration OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) teletrust(36) algorithm(3)
signature-algorithm(3) ecSign(2) ecStdCurvesAndGeneration(8)
}
ellipticCurve OBJECT IDENTIFIER ::= { ecStdCurvesAndGeneration 1 }
versionOne OBJECT IDENTIFIER ::= { ellipticCurve 1 }
brainpoolP320r1 OBJECT IDENTIFIER ::= { versionOne 9 }
```