No authentication secret
Neither the password nor credential-engine secrets travel through the pairing protocol.
Trust centre
Security
Protections are described with their real primitives, dependencies, and limits.
Primitives actually used
The channel between the PC and a paired device relies on .NET 8 standard-library primitives, with no third-party cryptographic dependency in the shared SDK.
- Device identity and signatures
- ECDSA P-256, used for pairing proofs and trust tokens.
- Key exchange
- Ephemeral ECDH P-256, a fresh pair for every pairing and every session resume.
- Key derivation
- HKDF-SHA256, with two distinct directional keys for PC → phone and phone → PC.
- Authenticated encryption
- AES-256-GCM, with a random nonce per message.
- Anti-replay
- A strictly increasing counter carried as associated data; any replayed or reordered message is rejected.
- Protection at rest
- Private key encrypted with DPAPI on the PC, and with Android secure storage on the phone.
What is never transmitted
No biometric data
Biometrics stay on the phone. ScreenShield21 receives an identity confirmation, never a fingerprint or a face.
No extensible scope
A paired device's capabilities are capped at four permissions; the protocol structurally carries no secret field.
A stated limit: no TLS on the local channel
The native Companion uses the local HTTP channel, with application messages encrypted by AES-256-GCM after pairing. The Web Companion uses an HTTPS tunnel that makes the local server transport accessible through a relay and requires Internet. The relay validates no proof and decides no unlock: that authority stays with the PC. The direct local channel has no TLS in this version.
None of these measures make a system unbreakable. They reduce specific risks, and their limits are written here on purpose.