invalid verification of signatures

[jakubzytka]

Signature verification in the verification tool (regkassen-demo-1.0.0.zip) is invalid.

Instead of just verifying provided signature against provided JOSE header and JWS Payload it performs base64url decoding and reencoding of the JWS Payload during the process.

As it is not true that base64urlEncode(base64urlDecode(data)) == data the tool is verifying different data than provided, which results in failed signature verification.

In particular, apache commons library used for base64 operations in the verification tool strips padding after base64url-encoding data. Such behavior is not required by https://tools.ietf.org/html/rfc4648 As a result, any JWS Payload which contains padding will not be accepted by the verification tool.

[ztp-mino]

see the actual JWS standard: https://tools.ietf.org/html/rfc7515, section 2 "Base64url Encoding"

it explicitly states that no padding is to be used in the JWS payload

[jakubzytka]

Thanks for this point. I think I know where does the misunderstanding come from now.

There are two issues - padding, and signature verification

Padding in base64 url encoding

As mentioned above, RFC 7515 redefines common term BASE64URL to something different than BASE64URL encoding defined in RFC 4648. It is very unfortunate that the term BASE64URL is used in RFC 7515 instead of e.g. BASE64JWS. But this is not the end of the story.

Anlage to Registrierkassensicherheitsverordnung defines:

Detailspezifikationen, point 6:

Das Ergebnis der JWS-Signatur ist die nach dem JWS-Standard definierte kompakte Repräsentation. Diese Zeichenkette besteht dabei aus drei BASE64-URL-kodierten Elementen, die durch das Zeichen „.“ voneinander getrennt sind.

and also: Detailspezifikationen, point 1:

Die folgenden Standards werden im Dokument unter den folgenden Abkürzungen verwendet:

• BASE32, BASE64, BASE64-URL: Network Working Group: Request for Comments: 4648 – The Base16, Base32, and Base64 Data Encodings

The law points RFC 4648 as the source of definition of BASE64URL. In my opinion RKSV overrides (perhaps not by design) RFC 7515 with regard to BASE64URL encoding, and thus paddings are allowed.

This sounds to be a legal dispute more than a technical one though.

Signature verification

If the payload contains padding the signature verification will fail with: "Die kryptographische Gültigkeit der Signatur ist nicht gegeben"

This is not true. ECDSA signature is perfectly valid.

Even if JWS with paddings is considered to be invalid due to RFC 7515 the integrity of the DEP is still guaranteed and no information is lost or modified due to presence of padding. The error on the other hand suggests someone might have tampered with DEP.

I think making it clear what is wrong may be a worthy improvement.

[ztp-mino]

I have to agree on both points. Unfortunately, those aren't the only warts on the Tool and the Detailspezifikationen Document and from the looks of it, neither is going to get updated anytime soon.