Idea name:
Secure Desktop App ↔ Browser Extension Pairing with Encrypted Handshake
Description:
Implement a secure handshake mechanism between a desktop application and a browser extension, where each generates a secret (Desktop Secret / Browser Secret) and displays them on a non-copyable canvas. A user manually enters the secrets into each application to bootstrap trust. The desktop app and browser extension then use derived AES keys to encrypt and exchange secrets, verifying each other’s identity and establishing a secure WebSocket channel with TLS. This ensures mutual authentication and end-to-end encryption for subsequent communications.
Use case:
As a user, I want to securely pair my desktop application with my browser extension so that I can ensure only legitimate parties connect to each other and securely exchange data.
Target user:
- Individuals or organisations requiring a level of security and privacy when interacting between a local desktop client and a browser extension.
Why this is important:
- Security: Prevents unauthorised extensions or apps from connecting, avoiding man-in-the-middle attacks.
- User Confidence: Manual secret entry ensures human-in-the-loop verification.
- Data Integrity & Privacy: AES encryption and TLS add multiple layers of protection.
- Compliance: Assists in meeting security standards requiring strong authentication and encryption.
Any other comments:
- This approach leverages well-understood cryptographic primitives (TLS, AES) while incorporating user interaction to defend against phishing or automated attacks.
- The non-copyable canvas display mitigates clipboard-based leaks.
High-Level Steps
1. Browser Extension Creates BS
- Browser Extension generates BS (Browser Secret).
- Browser Extension immediately derives
bK = AESKey(BS)
. - Browser Extension displays BS on a non-copyable canvas (so the user cannot just copy/paste).
2. User Inputs BS into Desktop App
- User enters BS into the Desktop App.
- The Desktop App acquires BS, which it needs to incorporate into its TLS certificate.
3. Desktop App Generates DS and TLS Certificate
- Desktop App generates DS (Desktop Secret).
- Desktop App immediately derives
dK = AESKey(DS)
. - The Desktop App then computes a salted hash for the certificate, example:
hashedBS = SHA256(BS | DS | randomSalt)
randomSalt
is newly generated cryptographically.- The Desktop App stores
hashedBS
andrandomSalt
locally.
- Desktop App embeds
hashedBS
andrandomSalt
in a custom certificate extension. - Desktop App finalises and signs the TLS certificate containing
hashedBS
+randomSalt
.- This certificate is now unique to the combination of BS + DS + salt.
- Desktop App displays DS on a non-copyable canvas.
4. User Inputs DS into Browser Extension
- User enters DS into the Browser Extension.
- Now the Browser Extension has both BS (its own secret) and DS (from the user).
- It can also compute
dK = AESKey(DS)
.
5. Browser Extension Verifies TLS Certificate
- Browser Extension retrieves the Desktop App’s TLS certificate.
- Browser Extension extracts
hashedBS
andrandomSalt
from the certificate extension. - Browser Extension recalculates
hashedBS_ext = SHA256(BS || DS || randomSalt)
. - Browser Extension compares
hashedBS_ext
to thehashedBS
from the certificate:- If mismatch, the certificate is not for this pairing; reject the connection.
- If match, the Browser Extension confirms the Desktop App’s certificate is specifically for BS + DS.
6. Standard Encrypted Handshake
- Browser Extension encrypts BS with
dK
→ Pairing Payload Request.dK = AESKey(DS)
was derived at step 11.
- Browser Extension sends the Pairing Payload Request via the TLS-secured WebSocket to the Desktop App.
- Desktop App (already has
dK
) decrypts the Pairing Payload Request → recovers BS.- Compares it with the user-entered BS (step 4).
- If mismatch, terminate.
- Desktop App generates a challenge token (CT).
- Desktop App (knowing BS) derives
bK = AESKey(BS)
. - Desktop App encrypts
(DS + CT)
withbK
→ Pairing Payload Response. - Desktop App sends the Pairing Payload Response to the Browser Extension over TLS.
- Browser Extension (already has
bK
) decrypts(DS + CT)
.- Verifies DS matches the DS from step 11.
- If mismatch, terminate.
- Browser Extension encrypts CT with
dK
and sends it back to the Desktop App. - Desktop App verifies the returned CT, confirming the Browser Extension’s identity.
- Secure communication proceeds with mutual authentication over TLS.
Mermaid Sequence Diagram
sequenceDiagram
autonumber
participant User
participant DesktopApp as Desktop App
participant BrowserExt as Browser Extension
Note over BrowserExt: (1) Generate BS
BrowserExt->>BrowserExt: (2) bK = AESKey(BS)
BrowserExt->>BrowserExt: (3) Display BS (non-copyable)
User->>DesktopApp: (4) Enter BS
DesktopApp->>DesktopApp: Acquire BS
DesktopApp->>DesktopApp: (5) Generate DS
DesktopApp->>DesktopApp: (6) dK = AESKey(DS)
DesktopApp->>DesktopApp: (7) hashedBS = SHA256(BS || DS || salt)
DesktopApp->>DesktopApp: (8) Embed hashedBS + salt in TLS cert
DesktopApp->>DesktopApp: (9) Sign final TLS certificate
DesktopApp->>DesktopApp: (10) Display DS (non-copyable)
User->>BrowserExt: (11) Enter DS
BrowserExt->>BrowserExt: dK = AESKey(DS)
BrowserExt->>DesktopApp: (12) Retrieve TLS certificate
BrowserExt->>BrowserExt: (13) Extract hashedBS + salt from cert
BrowserExt->>BrowserExt: (14) hashedBS_ext = SHA256(BS || DS || salt)
BrowserExt->>BrowserExt: (15) Compare hashedBS_ext with cert hashedBS
alt Certificate mismatch
BrowserExt->>BrowserExt: Reject/terminate
else
BrowserExt->>BrowserExt: Certificate is verified for BS + DS
end
BrowserExt->>BrowserExt: (16) Encrypt BS with dK -> Pairing Payload Request
BrowserExt->>DesktopApp: (17) Send Pairing Payload Request over TLS
DesktopApp->>DesktopApp: (18) Decrypt BS with dK
DesktopApp->>DesktopApp: Compare BS with user-entered BS
alt BS mismatch
DesktopApp->>DesktopApp: Terminate session
else
DesktopApp->>DesktopApp: BS verified
end
DesktopApp->>DesktopApp: (19) Generate challenge token (CT)
DesktopApp->>DesktopApp: (20) bK = AESKey(BS)
DesktopApp->>DesktopApp: (21) Encrypt (DS + CT) with bK -> Pairing Payload Response
DesktopApp->>BrowserExt: (22) Send Pairing Payload Response
BrowserExt->>BrowserExt: (23) Decrypt DS + CT with bK
BrowserExt->>BrowserExt: Compare DS to user-entered DS
alt DS mismatch
BrowserExt->>BrowserExt: Terminate session
else
BrowserExt->>BrowserExt: Desktop App authenticated
end
BrowserExt->>BrowserExt: (24) Encrypt CT with dK
BrowserExt->>DesktopApp: (25) Send encrypted CT back
Note over DesktopApp,BrowserExt: (26) Desktop App verifies CT; mutual authentication complete
Note over DesktopApp,BrowserExt: Secure session established
Security Considerations
Salting & Hashing:
- Prevents revealing BS in the certificate.
- Forces the Browser Extension to use both BS + DS to verify
hashedBS
, ensuring the extension cannot do certificate verification until it knows DS.
Certificate Authenticity:
- The Desktop App’s certificate is signed (e.g., self-signed or signed by a local CA).
- The Browser Extension verifies the signature and the custom field containing
hashedBS
.
Mutual Authentication:
- After verifying the certificate, the Browser Extension still sends the Pairing Payload Request (BS encrypted by dK).
- The Desktop App responds with
(DS + CT)
encrypted by bK. - A final challenge token seals the handshake, confirming each side’s identity.
Security Caveats:
- Must ensure robust random generation of
BS
,DS
,salt
, and ephemeral keys. - The Browser Extension must parse the certificate carefully and strictly verify the signature.
- No partial logging of secrets or hashed values in plaintext that could aid offline attacks.
With these measures, you achieve a highly secure handshake that binds the Desktop App’s certificate to the specific BS
+ DS
pairing, preventing rogue certificates and ensuring both sides confirm each other’s identities before establishing a secure connection.