auto sign files
linux at codehelp.co.uk
Tue Jan 18 23:48:14 CET 2005
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
> 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.
> 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
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
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
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
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
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.
> > 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
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : /pipermail/attachments/20050118/63a3a3cb/attachment-0001.pgp
More information about the Gnupg-users