search

SwitchEV / RISE-V2G

The only fully-featured reference implementation of the Vehicle-2-Grid communication interface ISO 15118
MIT License
219 stars 92 forks source link

Signature verification fails #17

Closed mrozigor closed 7 years ago

mrozigor commented 7 years ago

Latest update helped with SaleTarrif digest. But next step - verification - fails. It ends with exception thrown on EVCC side (with our SECC implementation).

Here are exception messages: 2017-09-28T09:49:01,669 ERROR [Thread-1] SecurityUtils: SignatureException occurred while trying to verify signature value java.security.SignatureException: Could not verify signature at sun.security.ec.ECDSASignature.engineVerify(ECDSASignature.java:325) ~[sunec.jar:1.8.0_151] at java.security.Signature$Delegate.engineVerify(Signature.java:1219) ~[?:1.8.0_144] at java.security.Signature.verify(Signature.java:652) ~[?:1.8.0_144] at org.v2gclarity.risev2g.shared.utils.SecurityUtils.verifySignature(SecurityUtils.java:1907) [classes/:?] at org.v2gclarity.risev2g.evcc.states.WaitForChargeParameterDiscoveryRes.verifySalesTariffs(WaitForChargeParameterDiscoveryRes.java:221) [classes/:?] at org.v2gclarity.risev2g.evcc.states.WaitForChargeParameterDiscoveryRes.processIncomingMessage(WaitForChargeParameterDiscoveryRes.java:124) [classes/:?] at org.v2gclarity.risev2g.evcc.session.V2GCommunicationSessionEVCC.update(V2GCommunicationSessionEVCC.java:178) [classes/:?] at java.util.Observable.notifyObservers(Observable.java:159) [?:1.8.0_144] at org.v2gclarity.risev2g.evcc.transportLayer.StatefulTransportLayerClient.processIncomingMessage(StatefulTransportLayerClient.java:119) [classes/:?] at org.v2gclarity.risev2g.evcc.transportLayer.TLSClient.run(TLSClient.java:169) [classes/:?] at java.lang.Thread.run(Thread.java:748) [?:1.8.0_144] Caused by: java.security.SignatureException: Invalid encoding for signature at sun.security.ec.ECDSASignature.decodeSignature(ECDSASignature.java:400) ~[sunec.jar:1.8.0_151] at sun.security.ec.ECDSASignature.engineVerify(ECDSASignature.java:322) ~[sunec.jar:1.8.0_151] ... 10 more Caused by: java.io.IOException: insufficient data at sun.security.util.DerInputBuffer.truncate(DerInputBuffer.java:135) ~[?:1.8.0_144] at sun.security.util.DerInputStream.subStream(DerInputStream.java:160) ~[?:1.8.0_144] at sun.security.util.DerInputStream.readVector(DerInputStream.java:415) ~[?:1.8.0_144] at sun.security.util.DerInputStream.getSequence(DerInputStream.java:331) ~[?:1.8.0_144] at sun.security.ec.ECDSASignature.decodeSignature(ECDSASignature.java:376) ~[sunec.jar:1.8.0_151] at sun.security.ec.ECDSASignature.engineVerify(ECDSASignature.java:322) ~[sunec.jar:1.8.0_151] ... 10 more

Here are data used to sign and verify signature:

ChargeParameterDiscoveryReq (EXI HEXDUMP): 8098020000000016732A5B0A895A1D1D1C0E8BCBDDDDDDCB9DCCCB9BDC99CBD5148BD8D85B9BDB9A58D85B0B595E1A4BD0D5A1D1D1C0E8BCBDDDDDDCB9DCCCB9BDC99CBCC8C0C0C4BCC0D0BDE1B5B191CDA59CB5B5BDC9948D958D91CD84B5CDA184C8D4D910311A4A218812B43A3A381D1797BBBBBB973B999737B93397AA2917B1B0B737B734B1B0B616B2BC3497A429687474703A2F2F7777772E77332E6F72672F323030312F30342F786D6C656E632373686132353642023A03052A4032C755CAC2D05E2680EA107627EE06274A84317B20A438204A81212811548BB71F178C8BBF6DB9FCC5B01BDE29E312E47D88FAEA2DBB2BD2CC4F522697F189F37F0BF74EB8AB69ED4D27175C36D58EB6620ED5FE51A42F69466071F9E825329001901861900223102400C23182209C80 Private key (HEXDUMP): D4A439D114963031781D4331842784F6F4AE2B0AFDE9C0BBF8F60E310B9A7AFD Public key (HEXDUMP): 0435A395084F19933A226E7D54E8784461AA9D7C9CBB68F76F28A87B8389EE6C3433A7AE0BE73615F1905D88BE65A7FEA9DF5B6C7D7FFBE64F6C0EC4ECE3F0B7BF SignedInfo element (EXI HEXDUMP): 808112B43A3A381D1797BBBBBB973B999737B93397AA2917B1B0B737B734B1B0B616B2BC3497A1AB43A3A381D1797BBBBBB973B999737B933979918181897981A17BC36B63239B4B396B6B7B93291B2B1B239B096B9B430991A9B22042332025687474703A2F2F7777772E77332E6F72672F54522F63616E6F6E6963616C2D6578692F4852D0E8E8E0745E5EEEEEEE5CEE665CDEE4CE5E646060625E60685EF0DAD8CADCC646E6D0C2646A6C84018913DFC3DBDA4DAC7D64DC7CFEEAB57CE527B7ECB75BC4B46C94EA7F678A3BA370 SignedInfo element (HASH HEXDUMP): D42212AC1B75F9272C7FE35222202514CBFD1A14C01EA7360559E7903609517E Calculated signature (HEXDUMP): 30450220502A11EA532DB9D4A224037182C7C3B4669242E54659F7C3328593FDFE855B13022100D340682C86947C21CCC472EEE5E552654E9E0739C6801D3C244859D953CDB5FF ECC curve: secp256r1 Hash algorithm: SHA256

Message is correctly decoded on EVCC side and generated hash for SignedInfo element is equal to above one. Also public key used to verify signature on EVCC side is equal to above one.

This signature validates in this tool. You only have to change sig.updateString(msg1); to sig.updateHex(msg1); to insert SignedInfo EXI HEXDUMP into "Message string to be signed" field.

I also tried to verify signature between RISEV2G SECC and EVCC, but SECC can't load moSubCA2.pkcs8.der (even if it is generated through included script), so verification fails.

Can you confirm this behavior nad check if there is problem in RV2G?

MarcMueltin commented 7 years ago

At first sight, I don't see a particular problem with RISE V2G. Since you get a signature exception, it seems to me that the format of the signatureValue is incorrect. It may not be a DER-encoded signature. That's what the function getDEREncodedSignature() is all about. Java needs a DER-encoded signature for its verify function.

Could you please debug the function getDEREncodedSignature() (https://github.com/V2GClarity/RISE-V2G/blob/master/RISE-V2G-Shared/src/main/java/org/v2gclarity/risev2g/shared/utils/SecurityUtils.java#L2038) step by step when trying to verify the SalesTariff signature and tell me if you found anything weird going on?

mrozigor commented 7 years ago

I tried to send raw values now and it works. So DER encoded ASN.1 structure doesn't work with RV2G ;) Do you know requirement number which states about signature encoding? I just want to know how it should be implemented ;).

Another question - shouldn't be DIgestValues as well as SignatureValue base64 encoded as it states in Annex J?

Also i think that there is small mistake in EVCC "WaitForChargeParameterDiscoveryRes.java", line 124 - shouldn't next two lines be enclosed in braces?

MarcMueltin commented 7 years ago

I can't tell you a specific requirement stating that an ECDSA signature should not be DER-encoded. But there is also none stating that it should be DER-encoded. Naturally, an ECDSA signature is just the pair of (r,s) values, two 32-byte values. It is a point on the elliptic curve with an (x,y) coordinate. If you take the example data from Annex J, you will find out that it is a plain (r,s) value rather than a DER-encoded signature.

Regarding your second question: The Base64 encoding is only needed if you need to transmit binary data (such as the signature for the SalesTariff) via text-based systems such as Webservices or email. Thus, Base64-encoding between EVCC and SECC, which exchange binary data, is wrong. See also NOTE 2 of Annex J: "In contrast to textual XML in the presentation of this example, EXI encodes binary data natively, so the base64 encoding step will not be applied there."

Thanks for the hint with line 124 in WaitForChargeParameterDiscoveryRes! The following lines should indeed be enclosed in braces.

mrozigor commented 7 years ago

Ok, thank you for clarification. So I think that we stick for now with raw signature date in message as well as binary encoding.

Again - thank you very much for your time.

MarcMueltin commented 7 years ago

You're welcome :) By the way: In case you didn't know: I also published an ISO 15118 Manual which, among other topics, explains in every little detail all the things you need to know when creating digital signatures for AuthorizationReq, CertificateInstallationRes, CertificateUpdateRes and ChargeParameterDiscoveryRes: http://v2g-clarity.com/en/iso15118-masterclass/ebook/

mrozigor commented 6 years ago

Hello again ;)

Can you look now for signatures on AuthorizationRequest? When I sign messages on my side (as SECC; not RV2G) RV2G-EVCC verifies signature as valid (in case of certificate installation and update responses). But when I try to verify signature made on RV2G-EVCC side (AuthorizationRequest) it fails. I also check it with online tool and between RV2G-SECC and RV2G-EVCC (it also fails).

Thanks

MarcMueltin commented 6 years ago

Hi,

without further details regarding what is the error message it is impossible to help you in this case. RISE V2G has been tested numerous times, including several test runs agains a test system, so I am very confident that it's implementation is correct. But again, your question is not providing enough detail that would allow me to help you any further.

What online tool do you mean? How do you create your certificates and private keys?

mrozigor commented 6 years ago

Problem was with incorrect private key encrypting. It works now.

What do you think about such improvement - when you receive private key and contract certificate (on EVCC side), check if public key connected with certificate is same as public key connected with private key?