I'm not sure but I believe that is correct.
I just use generated certs from below commands at client example.
-h 127.0.0.1 -p 4061 -c 18 -a High -P Gurux -t Verbose -T 4758414141414141 -N 0.0.43.0.1.255
And I added some functions to server example like this:
- After requested to generate public/private keys from meter, the created keys for server are saved as *.pem file on server sides.
- After requested to import certs from meter, the imported certs are saved as *.pem file on server sides.
- When the server is initializing, automatically import these keys and certs.
The keys are automatically saved for the security setup object so you don't need to do this if you don't want to do it like this. The reason for this is that the association views might have different certificates.
I'm trying to generate keys and certs using example codes on github, but it still not work authentication with ECDSA.
The client example returns "invalid command" error.
----
I tried like this :
1. Add context name to AssociationLogicalName (for Ecdsa object) on server example like this : "obj.getApplicationContextName().setContextId(ApplicationContextName.LOGICAL_NAME_WITH_CIPHERING);"
(When it is missing, client example returns "The application context name is not supported. Meter expects Logical Name referencing." error. So I added it.)
2. Run server example with no parameters.
3. Run client exaple with this parameters for generate keys and certs.
"-h 127.0.0.1 -p 4061 -c 18 -a High -P Gurux -t Verbose -T 4758414141414141 -N 0.0.43.0.7.255"
4. Run client example with this paramerers for connection test.
"-h 127.0.0.1 -p 4061 -c 23 -a HighECDSA -t Verbose -T 4758414141414141 -M 4142434445464748 -K GeneralSigning -V Suite1 -C AuthenticationEncryption -v 0.0.43.1.0.255"
Then the client example returns "invalid command" error.
You need to add this for addHighLevelAssociation method.
// Uncomment this if you want to use ciphered connection.
obj.getApplicationContextName().setContextId(ApplicationContextName.LOGICAL_NAME_WITH_CIPHERING);
Now High authentication is used without ciphering.
There are some improvements to this. The new version is in testing and it's released tomorrow.
However it still doesn't work well, so I ask it again.
I'm sorry to bother you with similar questions.
You said to me add below line for addHighLevelAssociation(), but I had already added it to addHighLevelAssociationEcdsa() method like this.
GXDLMSAssociationLogicalName obj = new GXDLMSAssociationLogicalName("0.0.40.0.8.255");
...
obj.getAuthenticationMechanismName().setMechanismId(Authentication.HIGH_ECDSA);
// I had added it below line
obj.getApplicationContextName().setContextId(ApplicationContextName.LOGICAL_NAME_WITH_CIPHERING);
And I had generated keys and certificates with High authentication (Client address: 18) to GXDLMSSecuritySetup("0.0.43.0.7.255") object.
Then I had tried to connect HighECDSA authentication (Client Address: 23) with these keys and certificates.
Finally, the client example had returned an 'Invalid Command' error.
Please let me know if I missed anything.
All codes are same with github examples.
(The only difference that is to add a setContextId for addHighLevelAssociationEcdsa method.)
The new version is released. There is a new association object for ECDSA.
NOTE! You need to remove 4061settings.xml file or you don't see it.
Run this to generate new key and import certificate from the meter.
-h YOUR_METER_IP_ADDRESS -p YOUR_METER_IP_PORT -c 18 -a High -P Gurux -t Verbose -T 4758436C69656E74 -N 0.0.43.0.8.255
If you want to connect with ECSA authentication you can do it like this:
Generate ney key:
-h YOUR_METER_IP_ADDRESS -p YOUR_METER_IP_PORT -c 18 -a High -P Gurux -t Verbose -T 4758436C69656E74 -N 0.0.43.0.7.255
Connect with client address 24 which is mapped for the ECDSA association.
-h YOUR_METER_IP_ADDRESS -p YOUR_METER_IP_PORT -c 24 -a HighECDSA -t Verbose -T 4758436C69656E74
I checked it works with some modification for addSecuredHighLevelAssociation() method like this:
- commented to secret setting.
- change mechanismId Authentication.HIGH to Authentication.HIGH_ECDSA
- set application context like this : obj.getApplicationContextName().setApplicationContext(3);
Hi,
Hi,
Did you update the certificates for the meter and you are using the correct meter certificate in the client?
BR,
Mikko
I'm not sure to use correct
Regards Gurux team.
I'm not sure but I believe that is correct.
I just use generated certs from below commands at client example.
-h 127.0.0.1 -p 4061 -c 18 -a High -P Gurux -t Verbose -T 4758414141414141 -N 0.0.43.0.1.255
And I added some functions to server example like this:
- After requested to generate public/private keys from meter, the created keys for server are saved as *.pem file on server sides.
- After requested to import certs from meter, the imported certs are saved as *.pem file on server sides.
- When the server is initializing, automatically import these keys and certs.
Hi,
Hi,
The keys are automatically saved for the security setup object so you don't need to do this if you don't want to do it like this. The reason for this is that the association views might have different certificates.
BR,
Mikko
Thanks for your answer.
Regards Gurux team.
Thanks for your answer.
I'm trying to generate keys and certs using example codes on github, but it still not work authentication with ECDSA.
The client example returns "invalid command" error.
----
I tried like this :
1. Add context name to AssociationLogicalName (for Ecdsa object) on server example like this : "obj.getApplicationContextName().setContextId(ApplicationContextName.LOGICAL_NAME_WITH_CIPHERING);"
(When it is missing, client example returns "The application context name is not supported. Meter expects Logical Name referencing." error. So I added it.)
2. Run server example with no parameters.
3. Run client exaple with this parameters for generate keys and certs.
"-h 127.0.0.1 -p 4061 -c 18 -a High -P Gurux -t Verbose -T 4758414141414141 -N 0.0.43.0.7.255"
4. Run client example with this paramerers for connection test.
"-h 127.0.0.1 -p 4061 -c 23 -a HighECDSA -t Verbose -T 4758414141414141 -M 4142434445464748 -K GeneralSigning -V Suite1 -C AuthenticationEncryption -v 0.0.43.1.0.255"
Then the client example returns "invalid command" error.
Please let me know if I Did something wrong.
Hi,
Hi,
I'll test this and get back to this topic later today.
BR,
Mikko
Hi,
Hi,
You need to add this for addHighLevelAssociation method.
// Uncomment this if you want to use ciphered connection.
obj.getApplicationContextName().setContextId(ApplicationContextName.LOGICAL_NAME_WITH_CIPHERING);
Now High authentication is used without ciphering.
There are some improvements to this. The new version is in testing and it's released tomorrow.
BR,
Mikko
Hi,
Hi,
Thank you for your kindness.
However it still doesn't work well, so I ask it again.
I'm sorry to bother you with similar questions.
You said to me add below line for addHighLevelAssociation(), but I had already added it to addHighLevelAssociationEcdsa() method like this.
GXDLMSAssociationLogicalName obj = new GXDLMSAssociationLogicalName("0.0.40.0.8.255");
...
obj.getAuthenticationMechanismName().setMechanismId(Authentication.HIGH_ECDSA);
// I had added it below line
obj.getApplicationContextName().setContextId(ApplicationContextName.LOGICAL_NAME_WITH_CIPHERING);
And I had generated keys and certificates with High authentication (Client address: 18) to GXDLMSSecuritySetup("0.0.43.0.7.255") object.
Then I had tried to connect HighECDSA authentication (Client Address: 23) with these keys and certificates.
Finally, the client example had returned an 'Invalid Command' error.
Please let me know if I missed anything.
All codes are same with github examples.
(The only difference that is to add a setContextId for addHighLevelAssociationEcdsa method.)
Hi,
Hi,
The new version is released. There is a new association object for ECDSA.
NOTE! You need to remove 4061settings.xml file or you don't see it.
Run this to generate new key and import certificate from the meter.
-h YOUR_METER_IP_ADDRESS -p YOUR_METER_IP_PORT -c 18 -a High -P Gurux -t Verbose -T 4758436C69656E74 -N 0.0.43.0.8.255
Then you can connect using ECDSA:
-h YOUR_METER_IP_ADDRESS -p YOUR_METER_IP_PORT -c 24 -a HighECDSA -t Verbose -T 4758436C69656E74 -K GeneralSigning -V Suite1 -C AuthenticationEncryption -v 0.0.43.1.8.255
If you want to connect with ECSA authentication you can do it like this:
Generate ney key:
-h YOUR_METER_IP_ADDRESS -p YOUR_METER_IP_PORT -c 18 -a High -P Gurux -t Verbose -T 4758436C69656E74 -N 0.0.43.0.7.255
Connect with client address 24 which is mapped for the ECDSA association.
-h YOUR_METER_IP_ADDRESS -p YOUR_METER_IP_PORT -c 24 -a HighECDSA -t Verbose -T 4758436C69656E74
BR,
Mikko
Thanks for your kindness.
Thanks for your kindness.
I checked it works with some modification for addSecuredHighLevelAssociation() method like this:
- commented to secret setting.
- change mechanismId Authentication.HIGH to Authentication.HIGH_ECDSA
- set application context like this : obj.getApplicationContextName().setApplicationContext(3);
I'll ask again if I have a new question.
Regards,
Wooreeinfo
Hi,
Hi,
You can use any authentication level you want to. General signing doesn't define what authentication level you need to use.
ECDSA authentication doesn't use secret so you can comment that out.
BR,
Mikko