Question - Regarding eID specification

Hello,

I'm working on a project involving the belgian eID card. We aim to use allow users to sign using their eID with this middleware. But some questions remain and we could not find the information elsewhere.

Is the private key of a citizen still the same after (s)he change his/her eID ? I would guess that the key pair do not change for a citizen and that is linked to the National Registry ID, otherwise we could not verify that a signed document is legit after a card change (for example). But is there some scenarii where the key pair could change ?
Same question for authentication.
Does the federal government store these key pairs ?

Can you provide some answer or link to ressources where we could find the answers ?

Thanks a lot !

Disclaimer: I'm not affiliated with BOSA; my expertise is in document signing. Take this with a decent-sized grain of salt, as I'm not familiar with the key management policies used in the Belgian government PKI.

I've worked with eID signing before, though.

Is the private key of a citizen still the same after (s)he change his/her eID ? I would guess that the key pair do not change for a citizen and that is linked to the National Registry ID

Note that the private keys for signing and authentication are distinct anyhow. There's a link to the national registry ID in the certificates on the card. As such, the link between key pair and national registry ID is given by the fact that a Belgian government CA issued and signed that certificate. But that's it.

Also, I'm not a lawyer (let alone an expert in privacy law), but given that these certificates store sensitive PII, you'll want to be very careful with how you process that information... IIRC it's still not allowed to simply tie a persistent user ID in your application to a national registry ID or eID public key. That has obvious privacy implications. So if you do things right, you won't even be able to care about cards being reissued, because you shouldn't be able to figure out that your user got a new card.

otherwise we could not verify that a signed document is legit after a card change (for example)

That's not how digital signatures work: as long as you can establish a link between the public half of the key pair and the identity of the signer after the fact (i.e. prove that the old certificate was valid at the time of signing), validating old signatures is not a problem. "Proper" document signatures (combined with trusted timestamps and embedded revocation information) are resilient against key/certificate changes. Producing such signatures requires care, but it's not exactly obscure technology: there are standards for that (see CAdES/PAdES/XAdES and friends). The documentation of one of my projects has some more info on how the basic principle works in PDF specifically.

Bottom line: there's no need to keep the keys the same when a card is reissued. In fact, that would fly in the face of a whole bunch of key management best practices: when using private keys stored in hardware (at least in the signing/auth use case), you typically want to generate the key pair on-device to make sure the copy of the private key on the card is the only one in existence. In the vast majority of cases, there's no operational benefit to making backups of private keys unless they're used for encrypting stuff, which the eID keys aren't intended for.

Again, I'm not sure how this is implemented in the eID system, but I'd be very surprised if the private keys ever existed anywhere outside the card with which they are supposed to be used.

Does the federal government store these key pairs ?

I sure hope they don't store the private half ;).

Thank you for your detailled answers and information.

Also, I'm not a lawyer (let alone an expert in privacy law), but given that these certificates store sensitive PII, you'll want to be very careful with how you process that information... IIRC it's still not allowed to simply tie a persistent user ID in your application to a national registry ID or eID public key.

We do not plan to store PII or anything that could identify someone. Even if we were allowed to (legally speaking) we would rather not because of all the security measures we would need to put in place.

That's not how digital signatures work: as long as you can establish a link between the public half of the key pair and the identity of the signer after the fact (i.e. prove that the old certificate was valid at the time of signing), validating old signatures is not a problem.

I used a bad example, as you explained. We want to put into place a voting system where users could vote using their eID. The vote would be open for a certain duration (multiple weeks). Of course a user can only vote once. When voting the user will sign a document (a message, no need for a whole document). A hash of the signed message + salt will be stored to avoid a user to vote multiple times. However. If a user vote at time D+0, changes its eID on D+5 and vote again on D+6, the signed message will be different if the key pair is not the same.

We though about it that way before: we don't need to use the signed message as an identifier to avoid multiple "votes" on the same question. We could use the national registry + salt (different for each question opened to vote to avoid tracking a user) as a way to identify if a user has already voted or not. And use a the signing to verify this is a legit user (belgian citizen). But, using that method, a malicious user could fake a national registry (and change it multiple time to vote on the same question), sign with the same eID and all votes would be counted. Which is why we wanted to use the key as a way to ensure that even a malicious user could not vote mutliple times (unless he stole eID and knows the PIN for each one.

I sure hope they don't store the private half ;).

Me either.

A hash of the signed message + salt will be stored to avoid a user to vote multiple times. However. If a user vote at time D+0, changes its eID on D+5 and vote again on D+6, the signed message will be different if the key pair is not the same.

Hmm, I see. Hashes of signatures won't remain stable on key changes, that's for sure.

You mentioned salting the national number to avoid tracking users, but of course some degree of tracking will always be required to prevent this sort of replay attack... Depending on how much tracking you can get away with, and whether you're OK with "eventual consistency" of voting records, you might be able to perform periodical revocation checking to invalidate votes with IDs that'd got revoked before the ballot closes (thus requiring people with new cards to recast their vote if they want it to count). Not sure if that's sound; just an armchair suggestion.

Anyhow, "traditional" PKI doesn't do very well in use cases where anonymity is required. It's pretty tricky stuff. You'll need both a lawyer and an actual cryptography engineer on staff to get this right, I guess ;).

Hi,

First of all: we have a mailinglist for these sorts of questions. Important announcements regarding the eID are made there, too; as such, if you're developing with the eID, we highly recommend you subscribe there.

You can subscribe at https://groups.google.com/g/eid-middleware-dev

Thank you for your detailled answers and information.

Also, I'm not a lawyer (let alone an expert in privacy law), but given that these certificates store sensitive PII, you'll want to be very careful with how you process that information... IIRC it's still not allowed to simply tie a persistent user ID in your application to a national registry ID or eID public key.

We do not plan to store PII or anything that could identify someone. Even if we were allowed to (legally speaking) we would rather not because of all the security measures we would need to put in place.

Sensible :-)

[...]

That's not how digital signatures work: as long as you can establish a link between the public half of the key pair and the identity of the signer after the fact (i.e. prove that the old certificate was valid at the time of signing), validating old signatures is not a problem.

I used a bad example, as you explained. We want to put into place a voting system where users could vote using their eID. The vote would be open for a certain duration (multiple weeks). Of course a user can only vote once. When voting the user will sign a document (a message, no need for a whole document). A hash of the signed message + salt will be stored to avoid a user to vote multiple times. However. If a user vote at time D+0, changes its eID on D+5 and vote again on D+6, the signed message will be different if the key pair is not the same.

Yes, that will happen.

The key pair is generated on the card, and it is not possible for anyone (even for the government) to extract the private half of the key. Even if it were (which it isn't), the key formats have changed a few times in the past (once to go from 1024-bit RSA to 2048-bit RSA, and then once again to go from RSA to ECDSA P-384)

So you shouldn't keep a hash of the public key, because it will change and then you have duplicate votes.

Instead, what you should do is keep track of the RRN number, which is stored in the DN of the certificate (attribute "serialNumber"), or alternatively also in the identity file (field with tag 0x6), which is signed by the RRN key on the card (and that key in turn is signed by the root key).

You'll thus need to do a certificate chain validation, and then parse the certificate's DN from which you extract the RRN number. This will not change, even if the user undergoes a name change for example, so that gives you a guarantee that there is no duplicate vote.

We though about it that way before: we don't need to use the signed message as an identifier to avoid multiple "votes" on the same question. We could use the national registry + salt (different for each question opened to vote to avoid tracking a user) as a way to identify if a user has already voted or not. And use a the signing to verify this is a legit user (belgian citizen). But, using that method, a malicious user could fake a national registry (and change it multiple time to vote on the same question), sign with the same eID and all votes would be counted. Which is why we wanted to use the key as a way to ensure that even a malicious user could not vote mutliple times (unless he stole eID and knows the PIN for each one.

Yeah, if the value is important, don't rely on the eid-viewer XML file format (which is unsigned) or on user-entered data.

I sure hope they don't store the private half ;).

Me either.

They don't.

Anyway, this is not a bug (and this is not exactly the correct location for it, either), so closing this. If you have further questions, feel free to send a message to the mailinglist.

Hi, thanks for the mailing list !

Anyway, this is not a bug (and this is not exactly the correct location for it, either), so closing this. If you have further questions, feel free to send a message to the mailinglist.

I did not know any other way to ask these questions, this why I opened an issue here. But Thank you for the mailing list !

Instead, what you should do is keep track of the RRN number, which is stored in the DN of the certificate (attribute "serialNumber"), or alternatively also in the identity file (field with tag 0x6), which is signed by the RRN key on the card (and that key in turn is signed by the root key). You'll thus need to do a certificate chain validation, and then parse the certificate's DN from which you extract the RRN number. This will not change, even if the user undergoes a name change for example, so that gives you a guarantee that there is no duplicate vote.

Thank you for the information ! I'll look into that.

I did not know any other way to ask these questions, this why I opened an issue here. But Thank you for the mailing list !

No worries; I had assumed that to be the case ;-)

Thank you for the information ! I'll look into that.

Glad to be of help.

Fedict / eid-mw

Question - Regarding eID specification #168