1
$\begingroup$

Every article about port knocking, for instance https://wiki.archlinux.org/index.php/Port_Knocking , declares this method as security by obscurity. Is the following enough to remove that title;

  • a scheme where a 2048 bit shared key is generated. Every 2 bytes of the key are chunked off to make a list of 128 port numbers (2048/8/2). These port numbers in order are then configured as the port knocking sequence.
  • the MAC address of the sender is also factored in (maybe as the first 6 bytes of the key)

Does this fix the "Security by obscurity" aspect of port knocking?

I understand that this is a sniffable method. Thanks for your feedback!

$\endgroup$
  • $\begingroup$ Why use 2048-bit shared key? The protocol could use 2048-bit public keys instead. With those you could implement a PAKE scheme. It is kind of possible to use PAKE scheme to "fix" "security by obscurity" aspect of port knocking, but the communication will become less efficient than in some other means. (In the end protocol likely becomes e.g. non-interactive zero knowledge proof.) $\endgroup$ – user4982 Apr 5 '15 at 11:50
  • $\begingroup$ Can you post some info about PAKE so I can research? $\endgroup$ – portforwardpodcast Apr 5 '15 at 12:04
  • $\begingroup$ en.wikipedia.org/wiki/Password-authenticated_key_agreement $\endgroup$ – user4982 Apr 5 '15 at 12:44
4
$\begingroup$

The essence of port knocking - namely, the concealment of a service behind a lightweight authenticator - does not categorically suffer from security through obscurity. It really depends on what the characteristics of the authenticator are. At one end of the spectrum, there is "open port 22 if a SYN packet is sent first to port 12345" (obscurity - even nmap becomes a legitimate port knocking client in this case), and at the other end of the spectrum is PK's big brother "Single Packet Authorization" (which can use 2048-bit GnuPG keys together with an HMAC for example). The fwknop SPA implementation can do the later: https://www.cipherdyne.org/fwknop/ (Disclaimer: I wrote fwknop, so I'm obviously biased, but I believe the point still stands.) You may find additional material in the fwknop tutorial useful: http://www.cipherdyne.org/fwknop/docs/fwknop-tutorial.html

Also, the best reference on Port Knocking and SPA is still Sebastien Jeanquier's thesis "An Analysis of Port Knocking and Single Packet Authorization": http://www.securitygeneration.com/wp-content/uploads/2010/05/An-Analysis-of-Port-Knocking-and-Single-Packet-Authorization-Sebastien-Jeanquier.pdf

$\endgroup$
  • $\begingroup$ Thank you very much. It turns out that single packet auth is pretty much what I was looking for. So I'm accepting the answer. Also your link has the title "Single Packet Authorization > Port Knocking" which is pretty sweet and exactly what I need. Thanks! $\endgroup$ – portforwardpodcast Apr 6 '15 at 8:29
3
$\begingroup$

No, it is still security by obscurity, specifically because it is sniffable. Anyone who is aware you are using this port knocking protocol will be able to listen in on which ports you hit and therefore retrieve the shared key, defeating this security layer entirely. Thus the security of your protocol depends completely on the algorithm and not solely (actually, not at all) on the cryptographic key.

This is effectively equivalent to sending your password over the wire and hoping that nobody is monitoring the traffic, with its sole redeeming feature being that a port knocking sequence is less obvious than a plaintext password and hence (through obscurity) hopefully not recognized as such. Which is misguided if the adversary knows your scheme.

$\endgroup$
  • $\begingroup$ And what about the case where this is a stand alone appliance with no internet access but an ethernet port. Is this enough to protect an ssh port? (The ssh port would also use public key crypto with no password) $\endgroup$ – portforwardpodcast Apr 5 '15 at 11:46
  • $\begingroup$ @portforwardpodcast What is your threat model? To sniff on your ethernet traffic someone would (presumably) have to at least physically be in the vicinity, whether this is a concern to you depends on your threat model. This doesn't make it any less of a security through obscurity scheme, however. $\endgroup$ – Thomas Apr 5 '15 at 11:53
  • $\begingroup$ I am inexperienced in assessing a threat model. It will be a raspberry pi in a block of epoxy. The appliance will be in a public space in a datacenter. There will be mostly good actors surrounding it. My goal is to confuse anyone with limited access. If they can take it home this scheme really does nothing. If the sequence is not guessed, it will hide the existence of ssh which will protect against future ssh vulnerabilities. The sequence is emitted (over a single ethernet cable) by a trusted laptop that is never left with the appliance $\endgroup$ – portforwardpodcast Apr 5 '15 at 12:03
  • $\begingroup$ The whole idea then, portforwardpodcast doesn't make much sense. If the device is surrounded by 'mostly good actors' and sequence is transmitted over 'single ethernet cable from trusted laptop' why care at all at securing SSH? Try to concentrate on limiting remote access to system via SSH, not do some obscure traffic exchanges because you believe it will secure the system better. Remember, what people building SCADA systems thought 30 years ago - and some of them still believe it holds - that as long as nobody will see what's going on, nobody will be able to break it. It's flawled approach. $\endgroup$ – Łukasz Bromirski Apr 8 '15 at 19:47

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.