2
$\begingroup$

For simplicity let's say I only have RSA and AES on my hands and I want Alice to talk with Bob over a secure channel. With secure I am implying no MITM and Alice and Bob know they are talking to each other and not someone else.

When Alice wants a secure channel with Bob, Alice will ask Bob for his RSA public key, sign a randomly generated AES key with her RSA private key, encrypt the signature and AES key with Bob's RSA public key and send this to Bob. Bob will ask Alice for her RSA public key, will decrypt the signature and AES key with his own RSA private key and verify the signature with Alice's public key. Now Alice and Bob can use the AES key for further communication ...

Am I correct that the part where Alice and Bob exchange their public keys is a potential MITM vector? How can Alice be sure she got Bob's public key and vice versa? Is this what PKIs primarily solve, as in Alice and Bob trusting a third party upfront that - for example - signs their public keys? Or am I missing the point completely and everything of the above is bogus?

$\endgroup$
  • $\begingroup$ Signing the DEK would be useless. Not all PKC applications need signing at all, but when you do it's either of the plaintext or the ciphertext (including critical parameters like IV), and which is needed when is much debated; there are many existing Qs on that. $\endgroup$ – dave_thompson_085 Aug 8 at 1:45
  • $\begingroup$ @dave_thompson_085 From my understanding the signing of the key by Alice is needed for Bob to actually verify that it is indeed a key from Alice. Or what am I missing here? $\endgroup$ – Num Lock Aug 8 at 6:02
  • $\begingroup$ It's of no value to know where a transient, throwaway DEKis from. People care, if at all, about the message or the data, and signing the DEK provides no assurance as to either of those. $\endgroup$ – dave_thompson_085 Aug 9 at 18:43
  • $\begingroup$ I got your point in the first post already. Could you instead elaborate how secure communication with just the symmetric key happens after that step, without Bob being able to tell Alice's key apart from Eve's key, since Eve could just as well generate a key and send it encrypted to Bob? $\endgroup$ – Num Lock Aug 13 at 6:47
  • $\begingroup$ Sorry, I misread you. I was thinking of the usual message schemes (like PGP or SMIME) with a single-use DEK, but when creating a channel that uses the DEK repeatedly you do want that key both encrypted (or not sent at all = DH) and authenticated (signed). The caveat then is you must use that key with AES in an authenticated mode (such as GCM) or else add data authentication (usually a MAC such as HMAC) because symmetric encryption including AES by itself does not prevent tampering. Sorry I was off the wrong bat; I will delete if you want to clean this up. $\endgroup$ – dave_thompson_085 Aug 16 at 5:02
3
$\begingroup$

Your understanding is correct. PKI would be the service that verifies that Bob's public key really belongs to someone named "Bob". As long as Alice trusts the certificate authority that certified Bob's public key, she can implicitly trust that the public key she sees really is Bob's, not Eve performing a MITM.

The internet is secured with web PKI, which is the network of Certificate Authorities that certify that a websites' public key really belongs to the domain it claims to belong to (for Domain Validation, or DV). It's far easier to trust a handful of CAs than it is to trust every single website you'll ever visit.

$\endgroup$
  • $\begingroup$ Especially since nowadays there's no such thing as a server for a webpage -- almost every page contains at least hundreds of components downloaded from dozens to hundreds of servers all over the world, most with meaningless names. Figuring out who your browser tried to talk to takes hours; manually verifying all of them would take weeks. $\endgroup$ – dave_thompson_085 Aug 8 at 1:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.