Important announcement regarding the use of hashes on the eID card

[Wouter Verhelst]

Dear developers,

In accordance with the general consensus among the academic and
cryptographic community that the SHA1 algorithm as a cryptographically
secure hashing algorithm is not as secure as it once was, an update of
the eID is in order. As such, approximately six months from now the
Belgian national registry will stop using the SHA1 algorithm as part of
its signature operations for new cards, replacing it with the SHA256
algorithm instead. Note that the exact date has not yet been decided
upon; when this changes, a new announcement will follow.

This change will have the following repercussions for services and
applications using the eID:
- The signature of the identity data (name, address, photo, etc) stored
on the card currently uses the SHA1 algorithm for any required hashing
operations; applications which verify this signature should be updated
so they support SHA256 hashes as well as SHA1 ones.
- Current eID cards have certificate chains that are signed using the
sha1WithRSAEncryption algorithm. Future cards will use the
sha256WithRSAEncryption algorithm instead. Applications which verify
the certificate chain should be audited to ensure they will continue
to function with SHA-256 hashes rather than SHA-1 ones.
- In relation to the above, cards using the SHA-256 hashing algorithm
will be signed under the new Belgian Root CA4, rather than the current
Belgian Root CA3. Systems which use root certificates as trust anchors
should ensure they have the CA4 certificate added to their certificate
store.

Please note that the Fedict-supported software, including the eid-applet
and the eid-viewer, has already been updated to support the SHA256 hash.

Users of such applications are encouraged to upgrade to the most recent
version of the relevant software at their earliest convenience, to
ensure uninterrupted operation of their service.

--
Wouter Verhelst

[Tom Pester]

Hello Wouter,

How can we test our (4) eid solutions that rely on beglian eID?

We have a test eID card second generation but this one uses the SHA1 hash function.

Is there an option to order a new test card?

Kr, Tom

[Wouter Verhelst]

Hello Tom,

On 18-05-16 09:22, Tom Pester wrote:
> Hello Wouter,
>
> How can we test our (4) eid solutions that rely on beglian eID?
>
> We have a test eID card second generation but this one uses the SHA1
> hash function.
> Is there an option to order a new test card?

No. However, about two months ago now I announced on this list the
availability of a docker container which, together with the PCSC proxy
test software that you probably already have, allows you to emulate
SHA256-cards.

You can read more about it here:

https://groups.google.com/forum/#!topic/eid-middleware-dev/gdigifwBJhc

> --
> You received this message because you are subscribed to the Google
> Groups "eID Middleware Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to eid-middleware-...@googlegroups.com
> <mailto:eid-middleware-...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.

--
Wouter Verhelst

[Tom Pester]

Hello Wouter,

Thanks for providing the solution that uses the wrapper winscard.dll. That seems like a good solution if physical test cards our not an option.

Out of interest, what is the reason that physical cards were not made available. A non technical user could perform the test as well.

We don't have any non windows solution. Also out of interest, how should one proceed in this case?

We currently have deployed v 4.1.13 of the eID viewer. Correlating its release and this announcement I suspect this release can handle SHA256.

Can you confirm this please? And is this the first release that supports it? This last question is usable for other users I think

Kr, Tom

> an email to eid-middleware-dev+unsub...@googlegroups.com
> <mailto:eid-middleware-dev+unsub...@googlegroups.com>.

[Wouter Verhelst]

On 18-05-16 10:04, Tom Pester wrote:
> Hello Wouter,
>

> Thanks for providing the solution that uses the wrapper winscard.dll.
> That seems like a good solution if physical test cards our not an option.
> Out of interest, what is the reason that physical cards were not made
> available. A non technical user could perform the test as well.

The contract with Zetes (the provider of test cards) was allowed to
expire (for budgetary reasons, I can't go into more detail than that),
so they no longer provide test cards now.

We wrote this as a stopgap measure. We are aware that it's not an ideal
situation, but it's better than nothing.

> We don't have any non windows solution. Also out of interest, how should
> one proceed in this case?

There is some support for non-windows in the test environment, but
unfortunately it appears that this is limited to Java software only.
This is what we got from Zetes; we did not have the time to fix that.

> We currently have deployed v 4.1.13 of the eID viewer. Correlating its
> release and this announcement I suspect this release can handle SHA256.
> Can you confirm this please?

I was going to say yes, that it supports SHA256, because when I
originally sent the below mail, I had run a quick test first, and didn't
get any error messages.

However, for unrelated reasons I noticed a few weeks back that the
current viewer doesn't actually produce an error message unless you ask
it to also validate the certificates. At that point I changed it so that
it would at least log an error in that case. After testing it again just
now, I find that it turns out that the current viewer does not, in fact,
support SHA256 yet.

I've just fixed that; we will produce a new release of the middleware
with a new viewer in the next few days. Look for v4.1.18.

Apologies for the mixup.

> And is this the first release that supports
> it? This last question is usable for other users I think

Certainly.

--
Wouter Verhelst

[Tom Pester]

Hello Wouter,

Thanks for the clarifications. The open communication is much appreciated.

I'll followup next week 25/6 for version 4.1.18 on url https://github.com/Fedict/eid-viewer/releases

Is this the official channel to get the latest version?

I see that there is already a 4.1.18 release at the above url but I assume its work in progress.

Kr, Tom

[Wouter Verhelst]

On 18-05-16 13:19, Tom Pester wrote:
> Hello Wouter,
>

> Thanks for the clarifications. The open communication is much appreciated.
>
> I'll followup next week 25/6 for version 4.1.18 on url
> https://github.com/Fedict/eid-viewer/releases
> Is this the official channel to get the latest version?

No, we release our binaries through eid.belgium.be. The viewer is part
of the "middleware" download (at least for OSX and Windows; on Linux
it's in a separate package).

> I see that there is already a 4.1.18 release at the above url but I
> assume its work in progress.

It is what we're going to release, unless problems are found in testing
(unlikely, but it could happen).

If you're impatient, you can either build it yourself or download an
automatic (unsigned) build through
https://dist.eid.belgium.be/continuous/viewer/ -- but there are no
guarantees here (for obvious reasons).

> --
> You received this message because you are subscribed to the Google
> Groups "eID Middleware Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to eid-middleware-...@googlegroups.com
> <mailto:eid-middleware-...@googlegroups.com>.

[Tom Pester]

Hello Wouter,

The release notes mention that eid viewer in the middleware V4.1.18 with support for SHA256 is still in the test phase?

I'll check back on 13/6. The deadline mentioned is 2016-06-18. Not that a flood of SHA256 signed eids is expected on that date but its possible that one will pop up in the weeks thereafter.

Source:

http://eid.belgium.be/nl/je_eid_gebruiken/de_eid-middleware_installeren/windows

Kr, Tom

> an email to eid-middleware-dev+unsub...@googlegroups.com
> <mailto:eid-middleware-dev+unsub...@googlegroups.com>.

[Tom Pester]

Hello Wouter,

Any news when V4.1.18 with eID viewer support for SHA256 will be the recommended version? its currently the the "Toekomstige versie"/future version http://eid.belgium.be/nl/je_eid_gebruiken/de_eid-middleware_installeren/windows 

We are doing an update round soon at my company and would not favor to wait for our next window.

Kr, Tom

[Frederik Vernelen]

Hello Tom,

That is planned for tomorrow.

It might be superseded by version 4.1.x soon, which is identical to 4.1.18, a part from the firefox addon.

(Our Firefox addon shows a warning message in Firefox 47, even if everything went fine).

If you install the firefox addon from the mozilla store, it will get updated automatically, as soon as mozilla has signed our new addon version, and version 4.1.x will give you no benefit.

Wkr,

 Frederik

Hello Wouter,

> an email to eid-middleware-...@googlegroups.com
> <mailto:eid-middleware-...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.

--
Wouter Verhelst

--

You received this message because you are subscribed to the Google Groups "eID Middleware Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to eid-middleware-...@googlegroups.com.

[Tom Pester]

V 4.1.18 is now the recommended version on http://eid.belgium.be/en/using_your_eid/installing_the_eid_software/windows

Thank you

 

[Vincent]

Hi All,

Why not for Linux http://eid.belgium.be/en/using_your_eid/installing_the_eid_software/linux where it is still eid-mw-4.1.9-v4.1.9.tar.gz ?

[Frederik Vernelen]

Hello Vincent,

Thanks for pointing that out,

It will be most lickely for next week though, in the meantime, you can find it here:
https://dist.eid.belgium.be/continuous/viewer/

--

[Ju V]

Hi Wouter,
Hi Group,

Does this also means that applications that manually checks for OCSP response by generating http(s) requests of type ("application/ocsp-request"), with the bouncycastle library (or any other) and a code like this will need a rewrite of code ?
Please note first/second line of code, where SHA1 is clearly specified :

    // Generate the id for the certificate we are looking for
    CertificateID id = new CertificateID(CertificateID.HASH_SHA1, issuerCert, serialNumber);

    // basic request generation with nonce
    OCSPReqGenerator gen = new OCSPReqGenerator();

    gen.addRequest(id);

    OCSPReq req = gen.generate();

    HttpURLConnection c = ....
    c.getOutputStream().write(req.getEncoded());


Shouldn't we change this code, for new certificates / eid cards, with an ASN1ObjectIdentifier that looks like this ?

    public static final ASN1ObjectIdentifier SHA256 = new ASN1ObjectIdentifier("2.16.840.1.101.3.4.2.1");

And so, for old eid cards/certificates, we keep CertificateID.HASH_SHA1 ?

See also :

org.bouncycastle.cert.ocsp.CertificateID
org.bouncycastle.asn1.ASN1ObjectIdentifier
org.bouncycastle.asn1.ASN1ObjectIdentifier.OIWObjectIdentifiers.idSHA1
org.bouncycastle.asn1.ocsp.CertID

In advance,
Thanks for your response,
Julien.

PS : I know that there is certainly a better way to achieve this, but this application is in "maintenance" state ; I won't be allowed to review all the architecture of the application...
But I am opened to suggestions if they need a small coding time ;)

On Wednesday, December 23, 2015 at 10:45:09 AM UTC+1, Wouter Verhelst wrote:

[Frederik Vernelen]

Hello,

I'm not familiar with the bouncy castle API, but if you have SHA1 hardcoded in your code, you'll have to rewrite it indeed for the SHA256 cards.

Can't bouncycastle fetch the signature algoritm (sha1RSA/ sha256/RSA) from the certificate?

Wkr,

 Frederik

--

[Frederik Vernelen]

Hello,

I've been informed that when using SHA1 as an index hash towards the OCSP responder, its generated 20 bytes are still sufficient to guarantee unicity.

So for the case you described above, no change will be needed for the new eID cards.

Wkr,

 Frederik

[Jeroen Ingelbrecht]

Hello Wouter,

When is the government going to rollout the use of SHA256 hashes?  We heard they started at the beginning of this week (04/07/2016) but that they are recalling these cards and the use of SHA256 would be postponed to a later date?

Can you:

1) confirm this;

2) tell us when the new hashes will be used;

Thanks

Op woensdag 23 december 2015 10:45:09 UTC+1 schreef Wouter Verhelst:

[Wouter Verhelst]

On 01-07-16 12:13, Frederik Vernelen wrote:
> Hello,
>
> I've been informed that when using SHA1 as an index hash towards the
> OCSP responder, its generated 20 bytes are still sufficient to guarantee
> unicity.
> So for the case you described above, no change will be needed for the
> new eID cards.

Indeed.

RFC6960 ("X.509 Internet Public Key Infrastructure Online Certificate
Status Protocol - OCSP") has this to say about the subject:

KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key
-- (i.e., the SHA-1 hash of the value of the
-- BIT STRING subjectPublicKey [excluding
-- the tag, length, and number of unused
-- bits] in the responder's certificate

In other words, the CertificateID should still be hashed with SHA-1.
This is the only case, however; for everything else, you need to use
SHA-256 for newer cards.

--
Wouter Verhelst

[Wouter Verhelst]

On 13-07-16 11:42, Verhelst Wouter (Consultant) wrote:
> On 01-07-16 12:13, Frederik Vernelen wrote:
>> Hello,
>>
>> I've been informed that when using SHA1 as an index hash towards the
>> OCSP responder, its generated 20 bytes are still sufficient to guarantee
>> unicity.
>> So for the case you described above, no change will be needed for the
>> new eID cards.

[...]

> In other words, the CertificateID should still be hashed with SHA-1.
> This is the only case, however; for everything else, you need to use
> SHA-256 for newer cards.

Correction; this is not the case, I was confused. The above refers to
the public key of the responder, not the public key of the certificate.

The certificate is selected by the issuerNameHash, issuerKeyHash, and
serialNumber fields in the CertID sequence of the OCSP request (RFC6960,
page 32). The hashing algorithm used for issuerNameHash and
issuerKeyHash is selected by the hashAlgorithm field in the same sequence.

The CertificateID is built by the client, and should be parsed by the
OCSP responder. I've just verified that the OCSP responder does
correctly reply to OCSP requests with SHA-1 as the hashing algorithm for
the Certificate ID sequence, even if the key was signed with SHA-2. So
it remains true that you may still sign with SHA-1 for the time being.

In fact, it turns out that signing with SHA-2 is not currently
supported. This feels wrong, and I'll take that up internally; for now,
the statement that you indeed don't need to update the used hashing
algorithm for the CertificateID sequence is correct. Long term, it may
be the case that switching to SHA-256 for all OCSP requests, including
those of cards with SHA-1, will be the way to go.

Regards,

--
Wouter Verhelst

[Wouter Verhelst]

Hi Jeroen,

Sorry about the late reply; I had to ask internally to get the proper
answer.

Contrary to what I believed myself, the rollout has actually already
happened. That is, SHA-256 cards are now in production, and may be
encountered in the field.

My apologies that I missed that and did not announce it (as I promised
earlier).

Kind regards,

> --
> You received this message because you are subscribed to the Google
> Groups "eID Middleware Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to eid-middleware-...@googlegroups.com

> <mailto:eid-middleware-...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.

--
Wouter Verhelst