Repository navigation
Identify genuine vs simulated G7 sensors from their identity certificate - #86
Merged
Merged
Conversation
A real G7 proves itself during pairing: it streams an X.509 P-256 certificate chain and signs the key challenge (ECDSA r‖s over SHA256(nonce)) with its leaf key. Loop discarded both. This validates them and records whether the sensor is a genuine Dexcom, the g7sim development emulator, or could not be verified. - G7SensorIdentity: SecTrust-pins the Dexcom sensor intermediate (DEX01PG2) and the emulator's dummy CA as trust anchors, and verifies the challenge signature against the leaf with CryptoKit. Chains to Dexcom → genuine, to the dummy CA → simulated, else unverified. - G7Authenticator captures the leaf cert, nonce, and signature during both pairing and session auth and evaluates authenticity; the verdict is threaded through the pairing path and session path into state and persisted across reconnects. - Settings shows a critical "Simulated Sensor" warning for the emulator, tappable to hide (resets on the next pairing) for development screenshots. - Every reading's HKDevice reports a "g7sim (Simulator)" manufacturer and model and drops Dexcom's UDI when simulated, so data synced to HealthKit and onward is never mistaken for a genuine G7. Validation never blocks a reading: an unrecognized sensor is treated as real. Six unit tests cover the verdicts against a real DXCMTR capture and the emulator's own certificate.
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
A real G7 proves itself during pairing: it streams an X.509 P-256 certificate chain (leaf →
DEX01PG2→DEX00PG1) and signs the key challenge (ECDSA r‖s over SHA256 of our nonce) with its leaf key. We were discarding both. This validates them and records whether the sensor is genuine Dexcom, the LoopKit/g7sim development emulator, or unverified.G7SensorIdentity: SecTrust with the Dexcom sensor intermediate (DEX01PG2) and the emulator's dummy CA pinned as anchors; CryptoKit verifies the challenge signature against the leaf. Dexcom chain →genuine, dummy CA →simulated, otherwiseunverified.G7Authenticatorcaptures the leaf, nonce and signature; the verdict flows through both the pairing path and the session-auth path intoG7CGMManagerState.sensorAuthenticityand persists across reconnects.HKDevicereports manufacturerg7sim (Simulator), model<model> Simulator, and no UDI, so synced data (HealthKit, Nightscout) is never mistaken for a genuine G7.Validation never blocks a reading: an unrecognized sensor is treated as real.
Testing
G7SensorIdentityTests) against a captured real DXCMTR chain/signature and the emulator's own Go-generated certificate: genuine, simulated, garbage cert, tampered signature, wrong length, wrong nonce.sensorAuthenticity = simulated, the warning appears, and hiding it persists.