Performance improvements and new sample apps. #434
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
davidz25
force-pushed
the
sample-apps
branch
5 times, most recently
from
7d023a8 to
6b1f8e8
Compare
davidz25
force-pushed
the
sample-apps
branch
2 times, most recently
from
412d14a to
569501f
Compare
suzannajiwani
approved these changes
Jan 23, 2024
identity-android/src/androidTest/java/com/android/identity/android/legacy/DynamicAuthTest.java
Outdated
Show resolved
Hide resolved
...y-android/src/main/java/com/android/identity/android/mdoc/transport/ConnectionMethodUdp.java
Show resolved
Hide resolved
...tity-android/src/main/java/com/android/identity/android/mdoc/transport/DataTransportUdp.java
Outdated
Show resolved
Hide resolved
This PR introduces two sample apps - `preconsent-mdl` and `age-verifier-mdl` - to help with pinpointing performance issues with the libraries. This helped identify two problems making both the reader and the holder feel sluggish. - Calling `BouncyCastle()` is extremely expensive and we were doing this in a number of utility functions, including `Util.coseKeyDecode()`. This is fixed by using variants that pass `BouncyCastle.PROVIDER_NAME` instead. This also requires fixing up apps and test cases to manually register BouncyCastle at startup. - Determining the EC curve for a `PublicKey` is very expensive and also potentially fragile. Instead, modify the whole library stack to pass the curve along the public key. This is possible because we always know the curve, either if we created the key ourselves or if we received it from the reader or issuer (through COSE_Key). There's still room for optimization but these two fixes already help a lot and the two new samples makes it easier to identify and fix other bottlenecks. Other changes: - Use version catalogs in identity and identity-android. - Introduce DataTransportUdp as a super-low-latency data transfer method. The goal of this is to be able to pinpoint bottlenecks in non-data-transfer related code. For example, prior to the performance fixes mentioned above, it would occasionally take almost 1000ms to process DeviceEngagement and send encrypted DeviceRequest. - Remove reportConnectionMethodReady() as it's not needed for any of the data transfer methods in ISO 18013-5. For our two proprietary data transfer methods (DataTransportTcp and DataTransportUdp), just have `connect()` block on a call to the kernel to get a port number assigned. - Have `Credential.findAuthenticationKey()` also take the domain. This was really just an oversight when we added started tying authentication keys to domains. - Add `onHandoverSelectMessageSent()` callback to `NfcEngagementHelper`. This gives the mdoc application an opportunity to signal to the user that it's now safe to remove the device from the NFC field, for example by vibration. - In `VerificationHelper`, add API to allow the application to specify which connection methods to offer via NFC Negotiated Handover (this was a long-standing TODO). Also, pre-warm these connections meaning that for "mdoc central client mode" the reader will advertise the BLE UUID before interaction happens. This means that the BLE stack in the holder's device will have a chance to cache this UUID and MAC for a faster connection when in the vicinity. - Add new experimental option to `DataTransportOptions` for the application to specify whether to include the BLE L2CAP PSM in the engagement data. Also add code to directly connect to L2CAP in case the PSM was found in the engagement data. Since this is not standardized yet, default this setting to off. Fixes Issue #387. Test: Manually tested and all unit tests pass. Signed-off-by: David Zeuthen <[email protected]>
davidz25
added a commit
that referenced
this pull request
Apr 19, 2024
At while ago (PR #434) we introduced the concept of warmed-up transports when using Negotiated Handover to speed up presentations. Unfortunately this introduced a bug where we didn't set the right BLEIdent on the GATT Server when using mdoc BLE central client mode. This caused a problem with some mdoc implementations which fails if the BLEIdent value isn't what they expect. Our own mdoc implementation will only warn if the BLEIdent read from the GATT server isn't what is expects. This behavior has existed for a while but it originally used to error out. Implementations using an old version of our code thus may not currently work with our current VerificationHelper if they're using Negotiated Handover. Fix this by setting the BLEIdent on a warmed-up connection right after receiving Handover Select. Tested this fix against an implementation known to fail if the BLEIdent isn't it should be. Test: Manually tested. Signed-off-by: David Zeuthen <[email protected]>
suzannajiwani
pushed a commit
that referenced
this pull request
Apr 22, 2024
At while ago (PR #434) we introduced the concept of warmed-up transports when using Negotiated Handover to speed up presentations. Unfortunately this introduced a bug where we didn't set the right BLEIdent on the GATT Server when using mdoc BLE central client mode. This caused a problem with some mdoc implementations which fails if the BLEIdent value isn't what they expect. Our own mdoc implementation will only warn if the BLEIdent read from the GATT server isn't what is expects. This behavior has existed for a while but it originally used to error out. Implementations using an old version of our code thus may not currently work with our current VerificationHelper if they're using Negotiated Handover. Fix this by setting the BLEIdent on a warmed-up connection right after receiving Handover Select. Tested this fix against an implementation known to fail if the BLEIdent isn't it should be. Test: Manually tested. Signed-off-by: David Zeuthen <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR introduces two sample apps -
preconsent-mdlandage-verifier-mdl- to help with pinpointing performance issues with the libraries.This helped identify two problems making both the reader and the holder feel sluggish.
Calling
BouncyCastle()is extremely expensive and we were doing this in a number of utility functions, includingUtil.coseKeyDecode(). This is fixed by using variants that passBouncyCastle.PROVIDER_NAMEinstead. This also requires fixing up apps and test cases to manually register BouncyCastle at startup.Determining the EC curve for a
PublicKeyis very expensive and also potentially fragile. Instead, modify the whole library stack to pass the curve along the public key. This is possible because we always know the curve, either if we created the key ourselves or if we received it from the reader or issuer (through COSE_Key).There's still room for optimization but these two fixes already help a lot and the two new samples makes it easier to identify and fix other bottlenecks.
Other changes:
Use version catalogs in identity and identity-android.
Introduce DataTransportUdp as a super-low-latency data transfer method. The goal of this is to be able to pinpoint bottlenecks in non-data-transfer related code. For example, prior to the performance fixes mentioned above, it would occasionally take almost 1000ms to process DeviceEngagement and send encrypted DeviceRequest.
Remove reportConnectionMethodReady() as it's not needed for any of the data transfer methods in ISO 18013-5. For our two proprietary data transfer methods (DataTransportTcp and DataTransportUdp), just have
connect()block on a call to the kernel to get a port number assigned.Have
Credential.findAuthenticationKey()also take the domain. This was really just an oversight when we added started tying authentication keys to domains.Add
onHandoverSelectMessageSent()callback toNfcEngagementHelper. This gives the mdoc application an opportunity to signal to the user that it's now safe to remove the device from the NFC field, for example by vibration.Fixes Issue #387.
Test: Manually tested and all unit tests pass.