Before commenting read Forum rules
Don't comment the topic if you have a new question.
You can create a new topic selecting correct category from Gurux Forum and then create a new topic selecting "New Topic" from the top left.
Forums
Hi, I just started exploring higher levels of security. At the moment I'm trying to use HLS with ECDSA.
Client is using java library and server is based on gxsimulator.
In my approach below I have only one problem with signing CSR for meter.
My approach is following:
1. Create keypair for digital signature
____client.getCiphering.setSigningKeyPair(kp)
2. Create self signed certificate using keypair
3. Connect to meter with HLS without ECDSA
4. Import client certificate to meter
____reader.readDLMSPacket(ss.importCertificate(client, certificate)[0], reply, buffer)
5. Generate keypair on meter
____reader.... ss.generateKeyPair(client, Digital_Signature)
6. Generate certificate on meter
____reader.... ss.generateCertificate(...)
____client.getData(buffer, info)
7. From collected data make Certificate request
____cert = new GXPkcs10((byte []) info.getValue());
8. HERE I'm stuck. I guess I need to use Pkcs10 to create and sign certificate
9. Import signed certificate to client and meter
____client.getCiphering().getCertificates().add(meterCert)
____reader.... ss.importCertificate(client, meterCert)
10. Close connection and change authentication to high ECDSA.
I also tried this:
Map.Entry<CertificateType, PublicKey> entry = new AbstractMap.SimpleEntry<>(CertificateType.DIGITAL_SIGNATURE, cert.getPublicKey());
client.getCiphering().getPublicKeys().add(entry);
Your examples and guides are using client and server in same code, so you can get server keypair on client side.
After I manage to make this work, I guess using encryption with SS1/SS2 will be easy.
So signing the certificate
So signing the certificate request was easy, but when I try to connect to server (both sides have certificates, public keys and keypairs for signature and agreement), client is set for encryption with suite 1 and authentication is HLS+ECDSA.
After successful AARQ and AARE, client sends ciphered action request:
Ciphered PDU: DD 08 00 00 00 00 00 00 00 09 08 56 55 54 73 73 31 74 31 08 41 42 43 44 45 46 47 48 00 00 01 02 01 02 00 54 21 00 00 00 00 EF EB A2 5C 9A DF D3 8F 4E 30 65 30 17 FB A1 63 A4 E7 20 49 BD FA 5F 34 98 B7 87 DF 18 48 E5 9A 78 66 18 DE 12 B2 38 37 34 44 BC BF CC 96 BD D3 CA F5 05 98 F0 4E 30 8A 95 2C C2 91 B1 A7 EE 06 3C 06 7D C2 64 73 45 5D 9B 45 98 B0 39 D1 57
PDU before encryption: C3 01 C1 00 0F 00 00 28 00 00 FF 01 01 09 40 97 6E 33 26 0C EE 27 C0 68 52 89 31 DD BE 2C 90 AF 0B 7C 68 8F EF D2 2E C6 DA CF D1 55 B6 75 09 5B F0 C0 DD 84 A2 A0 F9 86 7D 19 C8 41 77 0D 68 8D 16 CE EA AC 8E 25 52 4F 7E 3D 71 4A FA 86 6A
But when server is processing it, command C3 (195) gets somehow degraded to C2 (194) and then server code gets Invalid Command error on GXDLMSServerBase inside try catch on line 888:
sr.setReply(handleCommand(info.getCommand(), info.getData(), sr, info.getCipheredCommand()));
Maybe my steps are wrong. Once server and client have their certificates for signature and agreement, how can I connect using SS1 or SS2.
And then it sends back HDLC unacceptable frame: 7E A0 0A 27 00 02 0E F9 97 CC EC 7E
This should return reply in correct interface, because I'm using wrapper and when reply is in HDLC it is confusing.
I'm debugging this for a few days now and I found some other places, where your code needs some tweaks. All is regarding to using certificates etc.
Hi,
Hi,
We have made changes and release the new version today.
BR,
Mikko
Thank you, but your release
Thank you, but your release wasn't for java.
I just need a simple guidance.
What I need to do on client side and server side to connect with SS1/SS2, after certificates are exchanged.
I was hoping, that simple initialize connection from GXDLMSReader would work and it kind of works, but server is still using SS0 passwords to decipher Action request after AARQ and AARE.
I also tried using ephemeral keys (from this post https://www.gurux.fi/node/6923). AARQ -> keyAgreement from SecuritySetup -> save sharedSecret and after that I changed security method to Encryption on client. Requests were encrypted, but responses not.
Hi,
Hi,
Security Suite 1 client example is under work and we try to release it on Monday.
It will do all the things that you need to do. Security Suite is not very easy.
BR,
Mikko
Hi,
Hi,
how does it looks with this release? Do you need any help? I really need at least something because I need it for my thesis :) I realise now, that Security Suite is difficult.
I have some findings from debugging and maybe it will help. (Classes and lines from 4.0.24)
1. Why ciphering has certificates and then also map of public keys? It is used only once in GXCommon-2560. And also, there is no way to write certificate keys to this public keys map directly from client.
2.GXDLMSAssociationLogicalName-360 Signature is always using first certificate. I think it should find a correct certificate with according CN and usage. SN association has this also.
3.GXDLMS-4145. Aesparameters using blockCipher and authKey. Is that right? Shouldn't be there switch between suites and keys?
Those are just a few places, where my debugging was giving some errors.
I also noticed, that Director
Hi,
I also noticed, that Director is using SystemTitles in Certificates like this "CN=4142434445464748",
but java library is making this "CN=41 42 43 44 45 46 47 48"
In making selfigned certificate, there is this to translate String system title to Common Name:
GXDLMSSecuritySetup.systemTitleToSubject(systemTitle); This is using GXByteBuffer and its toString which is making spaces between bytes...
I hope it helps.
Thank you
Hi,
Hi,
1. Map of public keys was obsolete keys and it's now removed.
2. This is already fixed.
3. Keys are used with GMAC ciphering and authKey for ECDSA-256 and ECDSA-384.
There are a lot of changes for the next release for Security Suite 1.
BR,
Mikko
Hi,
Hi,
I'm just trying the new update and I'm not sure if it is working (SUITE_1), or what am I doing wrong.
It still uses Block Key and cipher_0.
Suite_1 is set and also all certificates are on both sides. I also tried all KA schemes, because I saw a few conditions, where it is used and from it the code determines if cipher_0 or cipher_1 should be used
[12:27:22.588] Standard: DLMS
[12:27:22.591] Security: ENCRYPTION
[12:27:22.592] System title: 56 55 54 36 31 38 35 30
[12:27:22.593] Authentication key: 56 55 54 42 52 41 75 74 68 4B 6F 68 6F 75 74 31
[12:27:22.593] Block cipher key 41 42 43 44 31 32 33 34 56 55 54 42 52 31 32 33
[12:27:22.661] TX: 00 01 00 12 43 FC 00 53 60 51 A1 09 06 07 60 85 74 05 08 01 03 A6 0A 04 08 56 55 54 36 31 38 35 30 8A 02 07 80 8B 07 60 85 74 05 08 02 02 AC 12 80 10 20 35 10 72 35 08 28 53 57 74 67 53 0C 27 70 15 BE 17 04 15 21 13 21 00 00 00 00 01 98 EE D1 DC CF 42 5F 8E 9B 47 75 7B 7E
[12:27:22.692] RX: 00 01 43 FC 00 12 00 5F 61 5D A1 09 06 07 60 85 74 05 08 01 03 A2 03 02 01 00 A3 05 A1 03 02 01 0E A4 0A 04 08 41 42 43 44 45 46 47 48 88 02 07 80 89 07 60 85 74 05 08 02 02 AA 12 80 10 02 03 47 60 5A 27 22 26 79 5A 07 53 68 54 38 00 BE 17 04 15 28 13 21 00 00 00 00 5E 7A C4 77 8D 74 C6 A1 EA 2B 3D 2A D3 42
[12:27:22.702] TX: 00 01 00 12 43 FC 00 26 CB 24 21 00 00 00 00 C3 99 2F D1 D5 90 5D 73 8E 64 47 8B 85 88 DC 71 AD B6 CC C4 83 B3 4F 5D 52 32 8A 92 F3 1C DA
[12:27:22.720] RX: 00 01 43 FC 00 12 00 1F CF 1D 21 00 00 00 01 03 D8 02 1B 29 63 DB 0B AD 37 EE 58 51 1F 7D 98 BC FD F2 C5 BD B5 46 C5
[12:27:25.889] TX: 00 01 00 12 43 FC 00 05 62 03 80 01 00
[12:27:25.897] RX: 00 01 43 FC 00 12 00 1E 63 18 80 01 00 BE 16 04 15 28 13 21 00 00 00 02 2C 80 0A 75 DF 64 5D A2 80 0D 0C 2A 05 13