Skip to content

Trusted entitlements: Use new signature verification format#1111

Merged
tonidero merged 8 commits into
new-trusted-entitlements-signature-formatfrom
toniricodiez/sdk-3200-verify-intermediate-signature-android-3
Jul 3, 2023
Merged

Trusted entitlements: Use new signature verification format#1111
tonidero merged 8 commits into
new-trusted-entitlements-signature-formatfrom
toniricodiez/sdk-3200-verify-intermediate-signature-android-3

Conversation

@tonidero

@tonidero tonidero commented Jun 29, 2023

Copy link
Copy Markdown
Contributor

Description

Third PR for SDK-3200

  • Adds support to the new signature format (salt + nonce + TS + etag + content)
  • Adds support for intermediate signatures verification
  • Makes nonce optional in preparation of static endpoint signing.

Based on #1109 and #1110.

@codecov

codecov Bot commented Jun 29, 2023

Copy link
Copy Markdown

Codecov Report

Merging #1111 (c5249fd) into main (e6e498c) will decrease coverage by 0.05%.
The diff coverage is 84.61%.

@@            Coverage Diff             @@
##             main    #1111      +/-   ##
==========================================
- Coverage   85.16%   85.12%   -0.05%     
==========================================
  Files         186      186              
  Lines        6554     6568      +14     
  Branches      929      932       +3     
==========================================
+ Hits         5582     5591       +9     
- Misses        601      603       +2     
- Partials      371      374       +3     
Impacted Files Coverage Δ
...com/revenuecat/purchases/strings/NetworkStrings.kt 0.00% <ø> (ø)
...s/common/verification/SignatureVerificationMode.kt 80.95% <66.66%> (-13.50%) ⬇️
...at/purchases/common/verification/SigningManager.kt 93.47% <89.28%> (-6.53%) ⬇️
...java/com/revenuecat/purchases/common/HTTPClient.kt 90.00% <100.00%> (+0.56%) ⬆️

@tonidero tonidero Jun 29, 2023

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently nonce will never be null if shouldSignResponse, but that will change with the new static endpoints we want to sign. Right now I can't add tests to this change due to that limitation.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A separate PR for that is fine 👍🏻

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wasn't sure whether to add these, but I thought it might be useful if we need to debug things. Also, they are test keys, not real keys so I think it should be fine.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that now we aren't using the real root key but a new test key. It was difficult to test using the real key since the current responses may become outdated once the intermediate key expires. Still plan to add some integration tests that test this against the backend.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm how so? The expiration is also encoded in the signature.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right but we don't have the real root private key in order to create a signed intermediate key with an expiration date far in the future. If not, we would need to be changing the signature every time the intermediate key expires I think? I guess maybe we could get a signature that expires far into the future but not sure if that would have any security concerns... Probably not but I will think about that a bit more

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oooh I see. I got around that by creating fake private and public root keys in some of these tests.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, that's what I'm doing here. I basically used test private/public keys to generate signatures with different values that I need. But we are not testing using the real production key as we were before... But I think it's fine if that's covered by integration tests that actually hit the backend.

@tonidero tonidero added the HOLD label Jun 29, 2023

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was unused now so I removed it

@tonidero

Copy link
Copy Markdown
Contributor Author

Marking it as ready for review but we need to hold this until the backend is deployed.

@tonidero tonidero marked this pull request as ready for review June 29, 2023 15:04
@tonidero tonidero requested a review from a team June 29, 2023 15:05

@NachoSoto NachoSoto left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a question about the double-layer architecture.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A separate PR for that is fine 👍🏻

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's slightly weird that this has both of these types. Why would IntermediateSignatureHelper not be inside SignatureVerifier?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh I see SigningManager is the type on top. But it seems like it only uses IntermediateSignatureHelper though?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, the root key is only used by the IntermediateSignatureHelper so we can probably just remove the signatureVerifier from here.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I removed the signatureVerifier field from the enum here: 9efce80. Lmk what you think!

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm how so? The expiration is also encoded in the signature.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if this check is needed, but it makes sense to me.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I didn't do this but it makes sense.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right but we don't have the real root private key in order to create a signed intermediate key with an expiration date far in the future. If not, we would need to be changing the signature every time the intermediate key expires I think? I guess maybe we could get a signature that expires far into the future but not sure if that would have any security concerns... Probably not but I will think about that a bit more

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I didn't do this but it makes sense.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍🏻

@tonidero tonidero force-pushed the toniricodiez/sdk-3200-verify-intermediate-signature-android-2 branch from e2cd630 to 01e5594 Compare June 30, 2023 07:12
Base automatically changed from toniricodiez/sdk-3200-verify-intermediate-signature-android-2 to main June 30, 2023 07:21
@tonidero tonidero force-pushed the toniricodiez/sdk-3200-verify-intermediate-signature-android-3 branch from 9efce80 to 0533130 Compare June 30, 2023 07:24
@tonidero tonidero changed the base branch from main to new-trusted-entitlements-signature-format July 3, 2023 10:54
@tonidero tonidero removed the HOLD label Jul 3, 2023
@tonidero

tonidero commented Jul 3, 2023

Copy link
Copy Markdown
Contributor Author

Merging into integration branch for now

@tonidero tonidero merged commit 15e79d8 into new-trusted-entitlements-signature-format Jul 3, 2023
@tonidero tonidero deleted the toniricodiez/sdk-3200-verify-intermediate-signature-android-3 branch July 3, 2023 10:55
tonidero added a commit that referenced this pull request Jul 7, 2023
### Description
Third PR for SDK-3200

- Adds support to the new signature format (salt + nonce + TS + etag +
content)
- Adds support for intermediate signatures verification
- Makes nonce optional in preparation of static endpoint signing.

Based on #1109 and #1110.
tonidero added a commit that referenced this pull request Jul 7, 2023
### Description
Integration branch for the changes in trusted entitlements. Includes
changes from:
- #1111 
- #1114 
- #1118 
- #1119 
- #1124
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants