Wrong logic for reverse engagement when the curve type for the EReader doesn't match the curve type for the EDevice #455
Comments
nicklaswj
pushed a commit
to nicklaswj/identity-credential
that referenced
this issue
Jan 24, 2024
In the context of reverse engagement, check whether the EReader sent a SessionEstablisment message or a SessionData message. If the EReader sent a SessionEstablishment message, use the public key in the message instead of the initial public key in the ReaderEngagement message.
nicklaswj
pushed a commit
to nicklaswj/identity-credential
that referenced
this issue
Feb 1, 2024
In the context of reverse engagement, check whether the EReader sent a SessionEstablisment message or a SessionData message. If the EReader sent a SessionEstablishment message, use the public key in the message instead of the initial public key in the ReaderEngagement message. Signed-off-by: Nicklas Warming Jacobsen <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently the function
com.android.identity.android.mdoc.deviceretrieval.DeviceRetrievalHelper.ensureSessionEncryptionassumes that if it's a reverse engagement, then it received aSessionDatamessage without checking and returns early.However this logic is wrong in the case where the EReader chose a initial curve type different from the EDevice curve type.
Draft ISO 18013-7, section A.7 Session Encryption point 2 specifies that if the EDevice key curve type in
DeviceEngagementmessage is different from the EReader curve type inReaderEngagementMessage, then the EReader should generate a new key-pair with the same curve as the EDevice key and send aSessionEstablishmentmessage with the new public key and the request. Otherwise it should send aSessionDatamessage with only the request.I'm preparing a PR to fix this behavior.
The text was updated successfully, but these errors were encountered: