3

Im making a project that consist of a client/server system that requires TLS without PKI..

Design Requirements:

The client MUST authenticate that it's communicating with 'THE' server

The server MUST authendicate that it's communicating with 'A' client

The communication MUST be confidential

The confidentiality of a session MUST NOT relay on the confidentiality of a previouse session (aka forward secrecy)

And the integrity of the transmited data MUST be verified

Im thinking of using DHE for PFS, SRP(or alternativly PSK) for authendication with AES/CBC cipher and SHA for integrity.

My questions are..

Is this protocol stack possible?

Is AES 256 CBC reliable for confidentiality?

Will all the requirements be met by this design?

And if the SRP/PSK password of a client is obtained by a third party will he be able to evasdrop on other clients?

ps: i'm aming for the highest security option possible

Thanks in advance for any feedback and sorry for any confussion caused, i just starter learning about crypto..

Aristos Miliaressis
  • 31
  • 1

1 Answers1

4

There is no need to use a PKI with TLS. The only thing a PKI does is to make the authentication part of TLS scale. When using self-signed certificates, PSK or similar all trust information (like certificates or pre-shared keys) need to be distributed to every communication peer in a secure way. These information need also be be kept up-to-date, i.e. when new communication partners get added, secrets gets compromised or similar. Using a PKI instead this process is reduced to sharing the trust anchors (root certificates) which rarely need to be updated and to regularly check if a certificate got revoked. Using PKI thus gives you an easy creation and sharing of new trust information and also revocation and replacement of compromised trust information.

If you already have full control over all communication peers and also have a secure way to distribute new trust information and also revoke these if compromised then you don't need to use a PKI. If you don't have this infrastructure yet then using a PKI might be the easier and probably more secure than implementing everything yourself.

As for the specific protocol stack you mention: While PSK/SRP authentication can be used in theory with DHE/ECDHE as key exchange as dave_thomson@ correctly pointed out in a comment below, these ciphers seem to be rarely implemented. But with certificate based authentication DHE/ECDHE is commonly used and self-signed certificate don't need a PKI either. Also, while AES with SHA-256 is secure ciphers using AEAD like the GCM ciphers are preferred today. And ECDHE is preferred compared to DHE.

And if the SRP/PSK password of a client is obtained by a third party will he be able to eavesdrop on other clients?

If the essential secret (pre-shared key, password, private key) is obtained an attacker will not be able to decrypt sniffed data if DHE/ECDHE is used for key exchange. I'm not sure how PSK/SRP key exchange behave in this regard. But in all cases the attacker can impersonate the peer and get access to the decrypted traffic inside a man in the middle attack. Since the attacker has the secret this can be done without the other party realizing the problem, i.e. the authentication still succeeds. This is one of the reasons revocation and replacement of such secrets needs to be implemented - which is already included in the PKI.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • First off thank you for your answer it was very informative but i believe i must clarify better, the project im talking about is a botnet C&C infastructure (this is entierly theoretical and for educational purposes im not asking for help to build malware, i probably dont have the skills to implement it) that said the initial concern i had with PKI is that the servers public key could be easily found and blacklisted or revoked for being part of malware or the RA could ask for too much identifing info – Aristos Miliaressis Jul 13 '17 at 00:31
  • what would be in your opinion the most apropriate solution that wouldnt be so prone to a single point of failure like the C&Cs cert being blacklisted? also when you say that a captured pre sharet key could be used in a MITM does that effect thw entire botnet or only the connections imvolving the compromised peer? – Aristos Miliaressis Jul 13 '17 at 00:31
  • There are indeed (EC)DHEkx+PSKauth and even RSAkx+PSKauth (!) ciphersuites: rfc4279,5487,5489, plus 6209 for ARIA, 6367 for Camellia, 6665 for AES-CCM, 7905 for ChaCha/Poly, where at least the first 3 of the last 4 are pretty much ignorable. OTOH SRP which effectively includes ephemeral (integer) DH can be combined with some additional auth (RSA, DSS) but not other kx. Although given the additional explanation, (EC)DHE+selfsigned would be better 'camoflaged' for malware -- PSK and SRP are so rare it's dead easy for monitors and IDS etc to catch them. – dave_thompson_085 Jul 13 '17 at 01:15
  • @dave_thompson_085: thanks for pointing out that DHE/ECDHE are actually specified with PSK/SRP - although it looks like they are not commonly implemented in the TLS stacks. – Steffen Ullrich Jul 13 '17 at 03:20
  • @AristosMiliaressis: Aiming for TLS which can both not be simply centrally switched off by revoking some certificates and still be undetectable is a very different question from the one you've asked. Actually this looks like an [XY problem](https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem) where Y is your attempt to tackle the previously unpublished problem by not using PKI whereas X is the actual problem of using TLS in a robust way for botnets. I recommend that you start a new question where you ask problem X instead. – Steffen Ullrich Jul 13 '17 at 03:27
  • @AristosMiliaressis: and as dave_thompson already hinted: not using a PKI with TLS is actually that uncommon that passive traffic analysis is already enough to detect this botnet - and then the traffic could simply be blocked. See also [Hiding in Plain Sight: Malware’s Use of TLS and Encryption](https://blogs.cisco.com/security/malwares-use-of-tls-and-encryption) about this topic. – Steffen Ullrich Jul 13 '17 at 03:29