web-eid / web-eid-system-architecture-doc Goto Github PK

It would be hepful if there was a collection of sample web eID authentication tokens (unverifiedCertificate, algorithm , signature, …) that could be used for token verification testing.

The tokens should be using a known static nonce and origin, and be provided for each signature algorithm ("ES256", "ES384", "ES512", "PS256", "PS384", "PS512", "RS256", "RS384", "RS512").

There are some test tokens in web-eid-authtoken-validation-java, but these are a) not easily usable without reverse-engineering the java package and b) only seem to be provided for the ES384 algorithm.

The web-eid javascript library accepts the nonce as a base64 encoded string. However this base64 string is never decoded as base64 into bytes but rather treated as a regular string. This causes confusion when implementing backend validation of the signature.

Essentially instead of doing this to calculate the data to sign (python like pseudocode):

Hash(Hash(origin.encode('utf-8')) + Hash(base64decode(nonce)))

This is done instead:

Hash(Hash(origin.encode('utf-8')) + Hash(nonce.encode('utf-8')))

At-least to me (I am not a security expert) this seems to also reduce the entropy of the nonce as instead of all possible bytes one is limited to the base64 alphabet. I have not tried supplying non-base64 data as the nonce, but my guess is that web-eid library will complain when the data is not valid base64.

Is there any plans on changing the nonce to be parsed as base64 by the app before creating the hash? Or can the documentation be adjusted to clarify that the data does not need to be base64 if its not treated as base64.

When creating a signature in a browser only the hash is sent to the client. It's not cryptographically backed which document the user is signing. As a result it's not only possible for the user to sign a different document, but the user actually has no means to know what is he signing. Providing the document before signing and .asice after signing in the web page UI does not solve the problem as the user may not have trust that the website provides correct files.

When creating a signature the whole document should be sent to the client, the hash should be produced on the client and UI should allow the user to see what is he signing.