Closed jenspfahl closed 10 months ago
"Enc- and decryption happens on the mobile device, right?" - No, there is a desktop client as well, and this thing should not be able to decrypt on its own.
The QR is more or less "oms00_......" - the same text you get when you encrypt something on the phone (OK, there is additional information to maintain integrity of the QR code sequence as well).
MessageComposer defines within method prepareRsaAesEnvelope
the contents of the header - after that, the AES encrypted data follows (which is specific to the use case aka applicationId). Your "related key alias" is position (3) within the header.
Ok, but for what is the RSA-encrypted AES key needed you send in the message? It looks like encryption inside encryption but if a hacker obtains the RSA private key also the AES encryption is compromised. So where is the advantage here?
Yes, if you give away your RSA key (which is hardware-protected on your mobile, the app does not "have" it) - you are screwed.
RSA can encrypt only a couple of bytes. So you generate a random AES key, use it to encrypt your bulk data, encrypt that AES key with RSA, and add it to your data along with the fingerprint of the RSA key required to decrypt the whole thing again as follows:
I see. And the public key can be shared with the desktop app?
Exactly, see Key Management
You wrote in Key Management:
If you generated your private key in the app or restored it, and you are using omsCompanion, you will need to share the private key with the latter, if you want to encrypt passwords on your desktop PC directly.
I see it problematic to share the private key. In this case you could also share a symmetric key. Or, as an idea, you generate two key pairs, one for the app and one for the omsCompanion. Then the user only exchanges the public keys. That would be a classic asymmetric key use case.
That's a typo :) you share a public key. There is no way to get the public key out of the hardware keystore.
Ah ok. That makes sense. Last question. How does the backup of the private key work? In case I lose my phone?
Very interesting concept! But what I don't get is why do you use asymmetric keys? Enc- and decryption happens on the mobile device, right? Why not use a symmetric key instead and expose the key alias? And what is the content of the QR code sequence I have to scan? Does it contain the related key alias and the public key?