Re: Concepts: Security and Obscurity

[Michael Rash <mbr () cipherdyne org>]

On Apr 12, 2007, Craig Wright wrote:

> Hi Daniel,
> I admit that I missed some of the posts initially concerning port
> knocking etc and thus I did not consider this in my initial response.
>
> Port knocking has the issue that it is not completely silent as is
> presumed. Most routers are not set to stop sending ICMP, TCP etc
> responses to other routers. In fact to do so is a violation of the
> internet standards. As such, information on ports is often available
> from the network infrastructure. Drop on firewalls does not stop an
> attacker finding what ports are running - it just means that they have
> to be a little more creative.
>
> Systems that ONLY drop packets stand out. They are not "stealthy" but
> rather the hole they make makes them extrememly visible.
>
> In port knocking the control is not highly effective, to take a quote:
>
> In 'Critique of Port Knocking', Arvind Narayana states:
> "Suppose you decide on a list of 32 valid ports (the current
> implementation
> allows up to 256). How long does the port knock sequence
> need to be? You might think that since each port is a 16-bit integer,
> you need 8 knocks, so that you get 8*16 bits or 128 bits of security
> (virtually unbreakable). But since each port has only 32 possible
> values (5 bits), what you actually get is only 8*5=40 bits of security
> (trivially breakable)!"

Port knocking is dead compared to Single Packet Authorization
(disclaimer: as the author of fwknop, I'm biased:
http://www.cipherdyne.org/fwknop).  Essentially all of the limitations
in port knocking are addressed by SPA including the issue you mention
above.

What I'm trying to do is reduce the attack surface of my SSH daemon.
I'm mostly concerned about a clever attacker that possesses a zero-day
exploit for a vulnerability in the particular version of SSHD that I'm
running.  Such an attacker is not going to bother with trying to brute-
force passwords or some such where logging or other monitoring is going
to help.  The main problem is that SSHD is listening and accessible at
all from arbitrary source addresses (I believe Daniel made this point).

Can you provide examples where the SPA mechanism could be bypassed?  If
not, would you agree that SPA enhances the security of a protected
daemon?

> Applied Cryptography by Bruce Schneier:
> "If I take a letter, lock it in a safe, hide the safe somewhere in New
> York, then tell you to read the letter, that's not security. Thats
> obscurity. On the other hand, if I take a letter and lock it in a
> safe, and then give you the safe along with the design specifications
> of the safe and a hundred identical safes with their combinations
> so that you and the worlds best safecrackers can study the locking
> mechanism - and you still can't open the safe and read the letter -
> thats security."

Yes, indeed.  This quote is appropriate in the context of SPA (and port
knocking too for that matter).  The details are completely known since
the source code is published - including the source to all ciphers.

Sebastien Jeanquier makes a good argument for why SPA does not suffer
from the security through obscurity problem in his Master's thesis:

http://web.mac.com/s.j/

SPA is about concealment.  So are passwords used to unlock various
ciphers and authentication mechanisms.  But passwords themselves are not
generally thought of as suffering from STO.  Neither should SPA.

--
Michael Rash
http://www.cipherdyne.org/
Key fingerprint = 53EA 13EA 472E 3771 894F  AC69 95D8 5D6B A742 839F



> Regards,
> Craig
>
> Narayanan A. (2004) 'A Critique of Port Knocking'. Newsforge, August
> 2004.
> Viewable from:
> http://software.newsforge.com/software/04/08/02/1954253.shtml
>
>
>
> Craig Wright
> Manager of Information Systems
>
> Direct +61 2 9286 5497
> Craig.Wright () bdo com au
>
> BDO Kendalls (NSW)
> Level 19, 2 Market Street Sydney NSW 2000
> GPO Box 2551 Sydney NSW 2001
> Fax +61 2 9993 9497
> www.bdo.com.au
>
> Liability limited by a scheme approved under Professional Standards Legislation in respect of matters arising within 
> those States and Territories of Australia where such legislation exists.
>
> The information in this email and any attachments is confidential.  If you are not the named addressee you must not 
> read, print, copy, distribute, or use in any way this transmission or any information it contains.  If you have 
> received this message in error, please notify the sender by return email, destroy all copies and delete it from your 
> system. 
>
> Any views expressed in this message are those of the individual sender and not necessarily endorsed by BDO Kendalls.  
> You may not rely on this message as advice unless subsequently confirmed by fax or letter signed by a Partner or 
> Director of BDO Kendalls.  It is your responsibility to scan this communication and any files attached for computer 
> viruses and other defects.  BDO Kendalls does not accept liability for any loss or damage however caused which may 
> result from this communication or any files attached.  A full version of the BDO Kendalls disclaimer, and our Privacy 
> statement, can be found on the BDO Kendalls website at http://www.bdo.com.au or by emailing administrator () bdo com 
> au.
>
> BDO Kendalls is a national association of separate partnerships and entities.
>
> -----Original Message-----
>
> From: Daniel Miessler [mailto:daniel () dmiessler com] 
> Sent: Thursday, 12 April 2007 11:08 AM
> To: Craig Wright
> Cc: krymson () gmail com; security-basics () securityfocus com
> Subject: Re: Concepts: Security and Obscurity
>
>
> On Apr 11, 2007, at 5:55 PM, Craig Wright wrote:
>
> > Except that the **Very* few is NOT 50,100 or even 1000 - it is many  
> > many
> > times that. Unless you have cheanged the nature of the hypothesis as I
> > suspect that you have done in the response (ie limiting access
> > addresses)
>
> Changed the nature of the hypothesis? What thread have you been  
> reading? Have you even RTA? I'm going to stop this here since you  
> don't seem to understand what PK or SPA is.
>
> Go back, check it out, and then we'll start again if there's any  
> confusion. I have a feeling you're a pretty bright guy who's simply  
> not talking about the same thing we are.
>
> --
> Daniel Miessler
> E: daniel () dmiessler com
> W: http://dmiessler.com
> G: 0xDA6D50EAC