لطفا منتظر باشید ...
Hack 7 Automate Cryptographic Signature Verification
Use scripting and key servers to automate the
chore of checking software authenticity.
One of the most
important things you can do for the security of your system is to be
familiar with the software you are installing. You probably will not
have the time, knowledge, or resources to actually go through the
source code for all of the software that you are installing. However,
verifying that the software you are compiling and installing is what
the authors intended it to be can go a long way toward preventing the
widespread distribution of Trojan horses. Recently, several
pivotal pieces of software (such as tcpdump, LibPCap, Sendmail, and
OpenSSH) have had Trojaned versions distributed. Since this is an
increasingly popular vector for attack, verifying your software is
critically important.
Why is this even an issue? Unfortunately, it takes a little bit of
effort to verify software before installing it. Either through
laziness or ignorance, many system administrators overlook this
critical step. This is a classic example of
"false" laziness, as it will likely
lead to more work for the sysadmin in the long run. This problem is
difficult to solve because it relies on the programmers and
distributors to get their acts together. Then
there''s the laziness aspect: many times, software
packages don''t even come with a signature to use for
verifying the legitimacy of what you''ve downloaded.
Often, signatures are available right along with the source code, but
in order to verify the code, you must then hunt through the site for
the public key that was used to create the signature. After finding
the public key, you have to download it, verify that the key is
genuine, add it to your keyring, and finally check the signature of
the code.
Here is what this would look like when checking the signature for
Version 1.3.28 of the Apache web server using
GnuPG (http://www.gnupg.org):
# gpg -import KEYS
# gpg -verify apache_1.3.28.tar.gz.asc apache_1.3.28.tar.gz
gpg: Signature made Wed Jul 16 13:42:54 2003 PDT using DSA key ID 08C975E5
gpg: Good signature from "Jim Jagielski <jim@zend.com>"
gpg: aka "Jim Jagielski <jim@apache.org>"
gpg: aka "Jim Jagielski <jim@jaguNET.com>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Fingerprint: 8B39 757B 1D8A 994D F243 3ED5 8B3A 601F 08C9 75E5
As you can see, it''s not terribly difficult to do,
but this step is often overlooked when you are in a hurry. This is
where this hack comes to the rescue. We''ll use a
little bit of shell scripting and what are known as key
servers to reduce the number of steps to
perform this process.
Key servers are a part of a public-key cryptography infrastructure
that allows you to retrieve keys from a trusted third party. A nice
feature of GnuPG is its ability to query key
servers for a key ID and to download the result into a local keyring.
To figure out which key ID to ask for, we rely on the fact that the
error message generated by GnuPG tells us which key ID it was unable
to find locally when trying to verify the signature.
In the previous example, if the key that GnuPG was looking for had
not been imported prior to verifying the signature, it would have
generated an error like this:
gpg: Signature made Wed Jul 16 13:42:54 2003 PDT using DSA key ID 08C975E5
gpg: Can''t check signature: public key not found
The following script takes advantage of that error:
#!/bin/sh
VENDOR_KEYRING=vendors.gpg
KEYSERVER=
KEYID="0x`gpg --verify $1 $2 2>&1 | grep ''key ID'' | awk ''{print $NF}''`"
gpg --no-default-keyring --keyring $VENDOR_KEYRING
--recv-key --keyserver $KEYSERVER $KEYID
gpg --keyring $VENDOR_KEYRING --verify $1 $2
The first line of the script specifies the
keyring in which the result from the key
server query will be stored. You could use
pubring.gpg (which is the default keyring for
GnuGP), but using a separate file will make managing vendor public
keys easier. The second line of the script specifies which key server
to query (the script uses ; another good one is
). The third line
attempts (and fails) to verify the signature without first consulting
the key server. It then uses the key ID it saw in the error, and
prepends an 0x in order to query the key server on
the next line. Finally, GnuPG attempts to verify the signature, and
specifies the keyring in which the query result was stored.
This script has shortened the verification process by eliminating the
need to search for and import the public key that was used to
generate the signature. Going back to the example of verifying the
Apache 1.3.28 source code, you can see how much more convenient it is
to verify the package''s authenticity:
# checksig apache_1.3.28.tar.gz.asc apache_1.3.28.tar.gz
gpg: requesting key 08C975E5 from HKP keyserver
gpg: key 08C975E5: public key imported
gpg: Total number processed: 1
gpg: imported: 1
gpg: Warning: using insecure memory!
gpg: please see http://www.gnupg.org/faql for more information
gpg: Signature made Wed Jul 16 13:42:54 2003 PDT using DSA key ID 08C975E5
gpg: Good signature from "Jim Jagielski <jim@zend.com>"
gpg: aka "Jim Jagielski <jim@apache.org>"
gpg: aka "Jim Jagielski <jim@jaguNET.com>"
gpg: checking the trustdb
gpg: no ultimately trusted keys found
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Fingerprint: 8B39 757B 1D8A 994D F243 3ED5 8B3A 601F 08C9 75E5
With this small and quick script, both the number steps needed to
verify a source package and the amount of time needed have been
reduced. As with any good shell script, it should help you to be lazy
in a good way: by doing more work properly, but with less effort on
your part.
