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
Hello,
For HLS ECDSA Authorization defined, that CtoS string (transferred in CallingAuthenticationValue of AARQ) have to be 32..64 bytes long.
While Gurux send only 16 bytes.
1: 00 01 00 01 00 01 00 4C 60 4A A1 09 06 07 60 85 74 05 08 01 01 A6 0A 04 08 45 4D 52 07 00 00 00 02 8A 02 07 80 8B 07 60 85 74 05 08 02 07 AC 12 80 10 51 1E 62 66 00 20 00 16 79 74 45 0D 0B 14 03 29 BE 10 04 0E 01 00 00 00 06 5F 1F 04 00 60 00 1D 01 00
<WRAPPER len="54" >
<TargetAddress Value="1" />
<SourceAddress Value="1" />
<PDU>
<AssociationRequest>
<ApplicationContextName Value="LN" />
<CallingAPTitle Value="454D520700000002" />
<SenderACSERequirements Value="1" />
<MechanismName Value="HighECDSA" />
<CallingAuthentication Value="511E6266002000167974450D0B140329" />
<InitiateRequest>
<ProposedDlmsVersionNumber Value="06" />
<ProposedConformance>
<ConformanceBit Name="GeneralProtection" />
<ConformanceBit Name="GeneralBlockTransfer" />
<ConformanceBit Name="Get" />
<ConformanceBit Name="Set" />
<ConformanceBit Name="SelectiveAccess" />
<ConformanceBit Name="Action" />
</ProposedConformance>
<ProposedMaxPduSize Value="0100" />
</InitiateRequest>
</AssociationRequest>
</PDU>
</WRAPPER>
regards,
Vitaly
Hi Vitaly,
Hi Vitaly,
You are right about this. This is broken and ECDSA authentication is not working at the moment. I'll add this to the worklist. The next release is next week.
BR,
Mikko
Hi, Mikko
Hi, Mikko
The new revision still send only 16 bytes for CallingAuthenticationValue in HLS ECDSA Authorization.
regards,
Vitaly
Hi,
Hi,
You are right. That is still on test and it's coming in part of the next release.
BR,
Mikko
Hi, Mikko
Hi, Mikko
Are you going to implement HLS ECDSA Authorization for Gurux.DLMS ?
regards,
Vitaly
Hi Vitaly,
Hi Vitaly,
It is implemented for the csharp. Get the latest version. Java is released as soon as tests of the new version are over and other programming languages will follow.
BR,
Mikko
Hi, Mikko
Hi, Mikko
GXDLMSDirector v 8.2.2109.301 includes Gurux.DLMS v 9.0.2.2109.201
Device Settings:
Authentication - HighECDSA
SecuritySuite - Suite1
Security - Authentication
Signing - OnePassDiffleHelman
AARQ message:
<AssociationRequest>
<ApplicationContextName Value="LN_WITH_CIPHERING" />
<CallingAPTitle Value="454D520700000001" />
<SenderACSERequirements Value="1" />
<MechanismName Value="HighECDSA" />
<CallingAuthentication Value="4C5F2A0C5D2C700A12443B2302400471" />
<glo_InitiateRequest Value="110000000001000000065F1F0400001E5DFFFF928CEBEE43CEB94718B87851" />
</AssociationRequest>
Back to top of this thread- CallingAuthentication Value for HighECDSA mechanism have to be 32..64 bytes long.
You can see, that GXDLMSDirector sends only 16 bytes CallingAuthenticationValue.
regards,
Vitaly
Hi Vitaly,
Hi Vitaly,
Thank you for pointing this out and you are right. I have misunderstood what you mean.
I create an issue from this.
http://www.gurux.fi/node/19098
Challenge is now from 32 to 64 bytes when ECDSA authentication is used.
BR,
Mikko
Hi, Mikko
Hi, Mikko
Couple questions about the implementation.
- Your issue assume 64 bytes challenges. Are you going to implement challenge's length configuration ?
- DLMS assumes the possibility to send in AARQ not only client's title, but also client's certificate in calling-AE-qualifier field. Are you going to implement this feature ?
regards,
Vitaly
Hi,
Hi,
Now when you said it, there will be ChallengeSize property. If it's zero, the random value is used.
Sending client's public key certificate in calling-AE-qualifier field is now in the testing phase. Because this is optional feature tests are made with all the meters that are supporting ECDSA authentication that we have (not many).
BR,
Mikko