Fetch verification certificate #1223
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
johnschoeman
force-pushed
the
jts-cert-hmac
branch
from
ace5fad
to
802049a
Compare
johnschoeman
commented
Jul 13, 2020
| @@ -16,8 +22,15 @@ export const AffectedUserProvider = ({ | |||
| }): JSX.Element => { | |||
| const [code, setCode] = useState(''); | |||
|
|
|||
| const generateHMACDigest = async () => { | |||
There was a problem hiding this comment.
I wasn't 100% sure where all of this wants to live. On the one hand this all could live in the ./hmac.ts and we could lean into treating it more of a service, on the other hand i like have having the application logic independent from the details of the crypto stuff. Especially considering that it's currently unclear if we should be fetching the certificate as soon as possible or only have the user has consented to sharing data.
johnschoeman
commented
Jul 13, 2020
app/bt/AffectedUserFlow/hmac.ts
Outdated
|
|
||
| import { ExposureKey } from './exposureKey'; | ||
|
|
||
| export const generateKey = async (): Promise<ArrayBuffer> => { |
There was a problem hiding this comment.
It might makes sense to add some specs for these functions.
johnschoeman
commented
Jul 13, 2020
johnschoeman
commented
Jul 13, 2020
| // }; | ||
|
|
||
| export const storeHMACKey = async (hmacKey: string): Promise<void> => { | ||
| // exposureKeyModule.storeHMACKey(hmacKey); |
There was a problem hiding this comment.
this work might makes sense in a separate pr.
johnschoeman
force-pushed
the
jts-cert-hmac
branch
from
5aad538
to
6c7585d
Compare
johnschoeman
commented
Jul 13, 2020
| }; | ||
|
|
||
| interface RawExposureKey { | ||
| key: null | string; |
There was a problem hiding this comment.
@mattThousand , noticing that we are getting keys that look like:
{"key": null, "rollingPeriod": 144, "rollingStartNumber": 2657520, "transmissionRisk": 0}, {"key": null, "rollingPeriod": 144, "rollingStartNumber": 2657376, "transmissionRisk": 0}, {"key": null, "rollingPeriod": 144, "rollingStartNumber": 2657232, "transmissionRisk": 0}, {"key": null, "rollingPeriod": 144, "rollingStartNumber": 2657088, "transmissionRisk": 0}, {"key": null, "rollingPeriod": 144, "rollingStartNumber": 2656944, "transmissionRisk": 0}, {"key": null, "rollingPeriod": 144, "rollingStartNumber": 2656800, "transmissionRisk": 0}, {"key": null, "rollingPeriod": 144, "rollingStartNumber": 2656656, "transmissionRisk": 0}, {"key": null, "rollingPeriod": 144, "rollingStartNumber": 2656512, "transmissionRisk": 0}, {"key": null, "rollingPeriod": 144, "rollingStartNumber": 2656368, "transmissionRisk": 0}, {"key": null, "rollingPeriod": 144, "rollingStartNumber": 2656224, "transmissionRisk": 0}, {"key": null, "rollingPeriod": 144, "rollingStartNumber": 2656080, "transmissionRisk": 0}, {"key": null, "rollingPeriod": 144, "rollingStartNumber": 2655936, "transmissionRisk": 0}, {"key": null, "rollingPeriod": 144, "rollingStartNumber": 2655792, "transmissionRisk": 0}, {"key": null, "rollingPeriod": 144, "rollingStartNumber": 2655648, "transmissionRisk": 0}
from the native layer.
Do you know why the key field is coming in a null ?
johnschoeman
commented
Jul 13, 2020
ios/BT/ExposureManager.swift
Outdated
| @@ -306,6 +306,36 @@ final class ExposureManager: NSObject { | |||
| } | |||
| } | |||
|
|
|||
| @objc func getExposureKeys(callback: @escaping RCTResponseSenderBlock) { | |||
There was a problem hiding this comment.
Lets remove this one as the Promise style seems to work.
Why: After verifying the users provided code to the verification server and receiving a token, we need to generated a hashed version of the users keys (and potentially metadata) and post this to verification server to receive a certificate which we can use to post exposure keys to the key server. This commit: Introduces the logic for generating and HMAC of the current exposure keys and posting this data along with the previously received token to api/certificate. We introduced react-native-simple-crypto for calculating the HMAC hashing on the JS side as this will reduce the amount of code that the native layer will need to implement. In a future iteration, it might make sense to do all of the cryptographic logic in the native layer as this will allow us to remove the dependency react-native-simple-crypto A native module promise, `ExposureKeyModule.fetchExposureKeys`, was added to fetch the exposure keys and serialize them to send the encrypted payload to the verification server. Next Steps: - Save the hmacKey to `realm` - Save the certificate generated on the verification server to `realm` - Post the exposure keys to the `GAEN` with the certificate and the HMAC key - Handle errors on the exposure keys, post exposure data flow - Add in user metadata to the request that goes to the Verification Server Co-Authored-By: Alejandro Dustet<aledustet@gmail.com>
aledustet
approved these changes
Jul 14, 2020
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.
Why:
After verifying the users provided code to the verification server and receiving a token, we need to generated a hashed version of the users keys (and potentially metadata) and post this to verification server to receive a certificate which we can use to post exposure keys to the key server.
This commit:
Introduces the logic for generating and HMAC of the current exposure keys and posting this data along with the previously received token to api/certificate.
We introduced react-native-simple-crypto for calculating the HMAC hashing on the JS side as this will reduce the amount of code that the native layer will need to implement. In a future iteration, it might make sense to do all of the cryptographic logic in the native layer as this will allow us to remove the dependency react-native-simple-crypto
A native module promise,
ExposureKeyModule.fetchExposureKeys, was added to fetch the exposure keys and serialize them to send the encrypted payload to the verification server.Next Steps:
realmrealmGAENwith the certificate and the HMAC keyCo-Authored-By: Alejandro Dustetaledustet@gmail.com