auto sign files

[Neil Williams]

On Tuesday 18 January 2005 8:05 pm, Jeff Fisher wrote:
> On Tue, Jan 18, 2005 at 12:33:18PM +0000, Neil Williams wrote:
> > On Tuesday 18 January 2005 9:08 am, Adam Cripps wrote:
> > > As a newbie in this area, I understand that there are at least two
> > > types of security - the most desirable security and more secure than
> > > now. This scenario fits in to the latter.
> >
> > Wrong - it falls into the security trap of being LESS secure than
> > current.
>
> How is it less secure?

Because security is more than just that one machine - from the perspective of 
the recipient, 'security' encompasses the whole transaction - from creating 
the file to installing the decrypted contents. If the file is changed before 
encryption (or used to replace a genuine encrypted file) and signed using an 
automated process, security has been breached. Yet the customer will receive 
no indication of the breach, therefore, from his/her perspective, the 
transaction using the automated process was insecure. S/He will rightly claim 
that you should have anticipated that such a breach would not be evident to 
them and should have taken steps to avoid such a situation. Therefore, the 
automated process has required the installation and monitoring of yet another 
layer of security to monitor intrusions - something that would not be a 
problem (even thought it would be wise to install) if the files could not be 
signed automatically.

> It is encrypted before it leaves the machine,

The original case was a file on a remote machine. This machine could be 
attacked. An attacker could easily replace the file, the details of the 
checksum that would be listed on the webpage of the site and, if the files 
are signed automatically, could also sign his own files to replace the 
originals, using the script. S/He wouldn't need to decrypt the original 
files, just overwrite them with his/her own and use the script to identify 
the key to be used for encryption of his own content. Encryption is no 
protection in this scenario.

Encryption is a red herring - if the source of an encrypted transmission is 
not secure, the encryption is pointless - this is all about the signatures. 
The only reason to encrypt these files is to determine who can decrypt the 
downloaded files - it does not protect the files on the server itself once an 
attacker has root/admin privileges.

> and  
> you can guarantee that it was either signed by the script, or signed by
> someone who broke into the machine. If it's the latter case, all bets are
> off,

Exactly. The recipient cannot tell if the machine has been compromised (the 
signature on an attacker's file would validate as well as an original file 
because the attacker can use the script).

Therefore, as the recipient, the fact that the signature verifies is NO 
indication that the contents are as expected. The signature then provides a 
false sense of security - waiting to catch out the unwary who take the 
signature to mean that the file is safe to use.

It would be more secure (overall) to be open and leave it unsigned - then the 
recipient is under no doubts that the content should be checked. From the 
perspective of the recipient (the customer in the original case), a signature 
made after an attack on the server should NOT verify. The fact that it DOES, 
means that the signature is entirely worthless. Acknowledging the risk leads 
to better overall security than trying to wish it away or obscure it under 
meaningless wrappers like automated signatures.

The recipient would not know - the checksum would be OK, the signature would 
be valid, the file would be encrypted to his/her public key - everything 
would check out until it was decrypted. Oops.

Far better to only have the secret key on a private machine. Copy the original 
files to that machine. Sign them there. Copy the files to the public host. 
Encrypt them anywhere along that line, by preference. Now the public host 
cannot be used to authenticate files created by the attacker - the recipient 
is alerted by the use of the wrong keyid or a bad signature, BEFORE 
decryption. Security, from the perspective of the recipient, is much 
improved.

Change the perspective a little - this has all centred on the remote machine. 
Think about this from the perspective of the recipient. In the original 
situation, the recipient (customer) was requiring encryption and signatures 
specifically in order to have some assurance about the security of the 
contents. If you automate the signing, the recipient can no longer be sure 
that the file contains what it is meant to contain, despite both the 
signature (using the script on the compromised machine) and the encryption 
(using the same script). No decryption is necessary, replacement files 
containing trojans or backdoors will look the same if padded to the same 
archive size as the expected file. That isn't hard - stick some (abusive) 
text at the end until you get the right file size. It'll look the same, the 
filename is easy, the same encryption key can be used, the signature will 
verify but the contents are not what is expected. Isn't that the definitive 
Trojan Horse?

This can only happen because the admin of the remote machine chose an insecure 
method to sign the files. Keep the secret key off the remote machine and even 
if the server is attacked, the attacker cannot move the attack onto the 
customer's machines.

Think about it - attack one server, replace the files with your own that 
create backdoors from every customer machine back to the attacked server - or 
another one somewhere else. Put some useful content in there as 
filler/spoiler, maybe output some complicated error message about a bad copy 
operation or whatever. This is a real threat - it's the idea behind all the 
internet worms that were used for DoS attacks and/or now used for sending 
spam. 

If the customer machines cannot be compromised (because the attacker can't 
sign the files with the right key), the attack stops at the server. Excellent 
news for you. Your customers are safe, the original encrypted files can 
easily be identified and are easily verified to detect any tampering. A few 
careful deletions, restoring a few files from elswhere, you're back up and 
running before some of your customers even notice.

All this comes undone if the attacker can create identical files with his/her 
own content to replace the genuine files. Now, even when you do discover the 
attack, you have to consider the key and all files on that server as 
compromised. There is no way to protect the key or older files that may 
contain genuine content, you'd have to decrypt them individually to verify 
them. All the signatures are valid because they are all generated using the 
same script. Your downtime goes through the roof as you try to replace maybe 
tens of thousands of customer files - many of which may be perfectly usable.

NOT GOOD!

> > Keep private keys on private machines.
>
> I belive the original problem was to automate this.  If you've never
> managed a production environment, automation means no private machines.

Precisely. Automation and convenience usually result in lower security. It's a 
compromise.

> As Adam said... This is more secure than the alternative.  If the machine
> is compromised, the key is comprimised, whether or not somebody is typing
> in the passphrase manually.

Important distinction here. If the key is only ever kept on a private machine, 
an attack on the public machine hosting the files does NOT compromise the 
key. Two machines - the private machine with the secret key and the public 
machine that hosts the final files. Plus the bonus of not having any 
automated signatures on the public machine - improves security and helps you 
out after any attack.

> To digress a bit, there is a concept in the real world called 'good
> enough'. It means that most company's security is not as tight as what is
> needed for the banking industry, which is not as tight as what is needed
> for the military, which is not as tight as what is needed for
> three-letter-agencies. Pick your spot in this scale, but don't force others
> to work up or down to this same level.

Equally don't hide the implications of getting the assessment wrong. We cannot 
presume to know what is good enough for the original enquirer - let them hear 
the opinion of those with different security needs and make their own 
decisions. As long as the decision is made in full knowledge of the possible 
problems, the group has served the enquirer well. If we hide the more complex 
problems from everyone, or fudge the issues or palm people off with soft 
security, how does that serve to further the use of GnuPG?

> Just a general impression -- I get the feeling you are trying to scare
> newbies away, rather than help them start using gnupg. Not everybody can 
> or will use gnupg to your standards, and if you say "It's my way or the
> hiway", you won't get many converts.

Never the intention, but those who ask about using a security program should 
be able to get a response from those who have higher security needs. It 
doesn't hurt to make the dangers known.

-- 

Neil Williams
=============
http://www.dcglug.org.uk/
http://www.nosoftwarepatents.com/
http://sourceforge.net/projects/isbnsearch/
http://www.williamsleesmill.me.uk/
http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /pipermail/attachments/20050118/63a3a3cb/attachment-0001.pgp