Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Interop with iOS #6

Closed
advatar opened this issue Aug 24, 2020 · 1 comment
Closed

Interop with iOS #6

advatar opened this issue Aug 24, 2020 · 1 comment

Comments

@advatar
Copy link
Contributor

advatar commented Aug 24, 2020 •
edited
Loading

Expected Behavior

You should be able to verify and present between iOS and Android

Actual Behavior

Nothing happens unless you add some calls to super

Steps to Reproduce the Problem

Specifications

  • Version:
  • Platform:

So, I have implemented all of this stuff in Swift for iOS including all the unit tests etc. It all works fine but interop between Android and iOS versions does not. I looked at some other BLE examples and saw that usually you need to invoke the super class f.i here:

https://github.com/google/mdl-ref-apps/blob/5c7dce58f475cfa1ff7f444f32a70b520db1d147/bleofflinetransfer/src/main/java/com/ul/ims/gmdl/bleofflinetransfer/peripheral/GattServer.kt#L226
like this:

super.onCharacteristicReadRequest(device, requestId, offset, characteristic)

When I do this it works (although a bit intermittently, I get timeouts) but when running Android as reader/verifier I get the request over the iOS holder, can decrypt the session and reply but the reader never gets the notification on the server2client characteristic. I wonder why it works Android-Android without this though.

So, I wonder if there is some other difference between iOS/Android. Setting up for notification is simpler on IOS and does not involve the CLIENT_CHARACTERISTIC_CONFIG descriptor. Why else should I look for here? Think I already tried invoking super. on the Central.
davidz25 added a commit that referenced this issue Jul 8, 2022
@davidz25
Fix double-wrapping of IssuerSignedItem.
3ffed6b 
The root problem is that both encodeStaticAuthData() and
decodeStaticAuthData() has a bug where IssuerSignedItem is wrapped in
a #6.24-tagged bstr twice.

For self-signed credentials provisioned on the device via
Utility.provisionSelfSignedCredential() this wasn't a problem because
those two bugs cancels each other out. However for applications where
the StatisAuthData (e.g. MSO and digest-id mapping) is generated
outside the device (the usual case for production-level mDLs) this was
a problem because the generated StaticAuthData CBOR failed to decode
because of the bug in decodeStaticAuthData().

Fix this by slightly reworking the API so IssuerSignedItem blobs are
passed around, not IssuedSignedItemBytes. Specifically this affects
the following public APIs:

 - Utility.mergeIssuerSigned()
 - Utility.decodeStaticAuthData()
 - Utility.encodeStaticAuthData()
 - DeviceResponseGenerator.addDocument()

This API change won't affect the common path where the mdoc
application is just using DeviceResponseGenerator.addDocument()
together with Utility.decodeStaticAuthData().

Additionally, since this is a bug in how StaticAuthData is encoded and
this is stored on disk, one will need to uninstall the reference app
and install it again to force creation of a new self-signed
credential.

Test: New unit tests and all unit tests pass.
Test: Manually tested with reference apps.
@davidz25 davidz25 mentioned this issue Jul 8, 2022
Merged
davidz25 added a commit that referenced this issue Jul 8, 2022
@davidz25
Fix double-wrapping of IssuerSignedItem.
ef7afce 
The root problem is that both encodeStaticAuthData() and
decodeStaticAuthData() have a bug where IssuerSignedItem is wrapped in
a #6.24-tagged bstr twice.

For self-signed credentials provisioned on the device via
Utility.provisionSelfSignedCredential() this wasn't a problem because
those two bugs cancels each other out. However for applications where
the StatisAuthData (e.g. MSO and digest-id mapping) is generated
outside the device (the usual case for production-level mDLs) this was
a problem because the generated StaticAuthData CBOR failed to decode
because of the bug in decodeStaticAuthData().

Fix this by slightly reworking the API so IssuerSignedItem blobs are
passed around, not IssuedSignedItemBytes. Specifically this affects
the following public APIs:

 - Utility.mergeIssuerSigned()
 - Utility.decodeStaticAuthData()
 - Utility.encodeStaticAuthData()
 - DeviceResponseGenerator.addDocument()

This API change won't affect the common path where the mdoc
application is just using DeviceResponseGenerator.addDocument()
together with Utility.decodeStaticAuthData().

Additionally, since this is a bug in how StaticAuthData is encoded and
this is stored on disk, one will need to uninstall the reference app
and install it again to force creation of a new self-signed
credential.

Test: New unit tests and all unit tests pass.
Test: Manually tested with reference apps.
davidz25 added a commit that referenced this issue Jul 8, 2022
@davidz25
Fix double-wrapping of IssuerSignedItem.
4b5fc7d 
The root problem is that both encodeStaticAuthData() and
decodeStaticAuthData() have a bug where IssuerSignedItem is wrapped in
a #6.24-tagged bstr twice.

For self-signed credentials provisioned on the device via
Utility.provisionSelfSignedCredential() this turned out to not be a
problem because the two bugs cancels each other out.

However for applications where the StaticAuthData (e.g. MSO and the
digest id mapping) is generated outside the device - the usual case
for production-level mDLs - this ends up being problem because the
generated StaticAuthData CBOR fails to decode because of the bug in
decodeStaticAuthData().

Fix this by slightly reworking the API so IssuerSignedItem blobs are
passed around, not IssuedSignedItemBytes. Specifically this affects
the following public APIs:

 - Utility.mergeIssuerSigned()
 - Utility.decodeStaticAuthData()
 - Utility.encodeStaticAuthData()
 - DeviceResponseGenerator.addDocument()

This change won't affect the common path where the mdoc application is
just using DeviceResponseGenerator.addDocument() together with
Utility.decodeStaticAuthData().

Additionally, since this is a bug in how StaticAuthData is encoded and
this is stored on disk, you'll need to uninstall the reference app and
install it again to force creation of a new self-signed credential.

Test: New unit tests and all unit tests pass.
Test: Manually tested with reference apps.
davidz25 added a commit that referenced this issue Jul 8, 2022
@davidz25
Fix double-wrapping of IssuerSignedItem.
6af1eb3 
The root problem is that both encodeStaticAuthData() and
decodeStaticAuthData() have a bug where IssuerSignedItem is wrapped in
a #6.24-tagged bstr twice.

For self-signed credentials provisioned on the device via
Utility.provisionSelfSignedCredential() this turned out to not be a
problem because the two bugs cancel each other out.

However for applications where the StaticAuthData (e.g. MSO and the
digest id mapping) is generated outside the device - the usual case
for production-level mDLs - this ends up being problem because the
generated StaticAuthData CBOR fails to decode because of the bug in
decodeStaticAuthData().

Fix this by slightly reworking the API so IssuerSignedItem blobs are
passed around, not IssuedSignedItemBytes. Specifically this affects
the following public APIs:

 - Utility.mergeIssuerSigned()
 - Utility.decodeStaticAuthData()
 - Utility.encodeStaticAuthData()
 - DeviceResponseGenerator.addDocument()

This change won't affect the common path where the mdoc application is
just using DeviceResponseGenerator.addDocument() together with
Utility.decodeStaticAuthData().

Additionally, since this is a bug in how StaticAuthData is encoded and
this is stored on disk, you'll need to uninstall the reference app and
install it again to force creation of a new self-signed credential.

Test: New unit tests and all unit tests pass.
Test: Manually tested with reference apps.
davidz25 added a commit that referenced this issue Jul 8, 2022
@davidz25
Fix double-wrapping of IssuerSignedItem.
2137f41 
The root problem is that both encodeStaticAuthData() and
decodeStaticAuthData() have a bug where IssuerSignedItem is wrapped in
a #6.24-tagged bstr twice.

For self-signed credentials provisioned on the device via
Utility.provisionSelfSignedCredential() this turned out to not be a
problem because the two bugs cancel each other out.

However for applications where the StaticAuthData (e.g. MSO and the
digest id mapping) is generated outside the device - the usual case
for production-level mDLs - this ends up being a problem because the
generated StaticAuthData CBOR fails to decode because of the bug in
decodeStaticAuthData().

Fix this by slightly reworking the API so IssuerSignedItem blobs are
passed around, not IssuedSignedItemBytes. Specifically this affects
the following public APIs:

 - Utility.mergeIssuerSigned()
 - Utility.decodeStaticAuthData()
 - Utility.encodeStaticAuthData()
 - DeviceResponseGenerator.addDocument()

This change won't affect the common path where the mdoc application is
just using DeviceResponseGenerator.addDocument() together with
Utility.decodeStaticAuthData().

Additionally, since this is a bug in how StaticAuthData is encoded and
this is stored on disk, you'll need to uninstall the reference app and
install it again to force creation of a new self-signed credential.

Test: New unit tests and all unit tests pass.
Test: Manually tested with reference apps.
davidz25 added a commit that referenced this issue Jul 11, 2022
@davidz25
Fix double-wrapping of IssuerSignedItem.
0e74620 
The root problem is that both encodeStaticAuthData() and
decodeStaticAuthData() have a bug where IssuerSignedItem is wrapped in
a #6.24-tagged bstr twice.

For self-signed credentials provisioned on the device via
Utility.provisionSelfSignedCredential() this turned out to not be a
problem because the two bugs cancel each other out.

However for applications where the StaticAuthData (e.g. MSO and the
digest id mapping) is generated outside the device - the usual case
for production-level mDLs - this ends up being a problem because the
generated StaticAuthData CBOR fails to decode because of the bug in
decodeStaticAuthData().

Fix this by slightly reworking the API so IssuerSignedItem blobs are
passed around, not IssuedSignedItemBytes. Specifically this affects
the following public APIs:

 - Utility.mergeIssuerSigned()
 - Utility.decodeStaticAuthData()
 - Utility.encodeStaticAuthData()
 - DeviceResponseGenerator.addDocument()

This change won't affect the common path where the mdoc application is
just using DeviceResponseGenerator.addDocument() together with
Utility.decodeStaticAuthData().

Additionally, since this is a bug in how StaticAuthData is encoded and
this is stored on disk, you'll need to uninstall the reference app and
install it again to force creation of a new self-signed credential.

Test: New unit tests and all unit tests pass.
Test: Manually tested with reference apps.
@davidz25
Copy link
Contributor

This issue is two years old closing... since then, I've tested our app against many iOS implementations and it seems to work just fine. Feel free to reopen if something is still wrong and I'll try to be better at responding and hopefully it won't take another two years - thanks!

@vaimut vaimut mentioned this issue Aug 8, 2024
Closed
@vaimut vaimut mentioned this issue Oct 25, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@advatar @davidz25