OnWorks Linux and Windows Online WorkStations


Free Hosting Online for WorkStations

< Previous | Contents | Next >

8.3.6. Validating Package Authenticity‌

System upgrades are very sensitive operations and you really want to ensure that you only install official packages from the Kali repositories. If the Kali mirror you are using has been compro- mised, a computer cracker could try to add malicious code to an otherwise legitimate package. Such a package, if installed, could do anything the cracker designed it to do including disclose passwords or confidential information. To circumvent this risk, Kali provides a tamper-proof seal to guarantee—at install time—that a package really comes from its official maintainer and hasn’t been modified by a third party.

The seal works with a chain of cryptographic hashes and a signature. The signed file is the Release file, provided by the Kali mirrors. It contains a list of the Packages files (including their com- pressed forms, Packages.gz and Packages.xz, and the incremental versions), along with their MD5, SHA1, and SHA256 hashes, which ensures that the files haven’t been tampered with. These

Packages files contain a list of the Debian packages available on the mirror along with their hashes, which ensures in turn that the contents of the packages themselves haven’t been altered either.

The trusted keys are managed with the apt-key command found in the apt package. This program maintains a keyring of GnuPG public keys, which are used to verify signatures in the Release.gpg files available on the mirrors. It can be used to add new keys manually (when non-official mirrors are needed). Generally however, only the official Kali keys are needed. These keys are automati- cally kept up-to-date by the kali-archive-keyring package (which puts the corresponding keyrings in /etc/apt/trusted.gpg.d). However, the first installation of this particular package requires caution: even if the package is signed like any other, the signature cannot be verified externally. Cautious administrators should therefore check the fingerprints of imported keys before trusting them to install new packages:


# apt-key fingerprint


---------------------------------------------------------- pub 4096R/2B90D010 2014-11-21 [expires: 2022-11-19]

Key fingerprint = 126C 0D24 BD8A 2942 CC7D F8AC 7638 D044 2B90 D010

uid Debian Archive Automatic Signing Key (8/jessie) <ftpmaster@debian.org>


------------------------------------------------------------------- pub 4096R/C857C906 2014-11-21 [expires: 2022-11-19]

Key fingerprint = D211 6914 1CEC D440 F2EB 8DDA 9D6D 8F6B C857 C906

uid Debian Security Archive Automatic Signing Key (8/jessie) <ftpmaster@debian.org>


------------------------------------------------------- pub 4096R/518E17E1 2013-08-17 [expires: 2021-08-15]

Key fingerprint = 75DD C3C4 A499 F1A1 8CB5 F3C8 CBF8 D6FD 518E 17E1

uid Jessie Stable Release Key <debian-release@lists.debian.org>


----------------------------------------------------------- pub 4096R/473041FA 2010-08-27 [expires: 2018-03-05]

Key fingerprint = 9FED 2BCB DCD2 9CDF 7626 78CB AED4 B06F 4730 41FA

uid Debian Archive Automatic Signing Key (6.0/squeeze) <ftpmaster@debian.org>


-------------------------------------------------------- pub 4096R/B98321F9 2010-08-07 [expires: 2017-08-05]

Key fingerprint = 0E4E DE2C 7F3E 1FC0 D033 800E 6448 1591 B983 21F9

uid Squeeze Stable Release Key <debian-release@lists.debian.org>


---------------------------------------------------------- pub 4096R/46925553 2012-04-27 [expires: 2020-04-25]

Key fingerprint = A1BD 8E9D 78F7 FE5C 3E65 D8AF 8B48 AD62 4692 5553

uid Debian Archive Automatic Signing Key (7.0/wheezy) <ftpmaster@debian.org>


------------------------------------------------------- pub 4096R/65FFB764 2012-05-08 [expires: 2019-05-07]

Key fingerprint = ED6D 6527 1AAC F0FF 15D1 2303 6FB2 A1C2 65FF B764

uid Wheezy Stable Release Key <debian-release@lists.debian.org>



pub 4096R/7D8D0BF6 2012-03-05 [expires: 2018-02-02]

Key fingerprint = 44C6 513A 8E4F B3D3 0875 F758 ED44 4FF0 7D8D 0BF6

uid Kali Linux Repository <devel@kali.org> sub 4096R/FC0D0DCB 2012-03-05 [expires: 2018-02-02]



pub 4096R/7D8D0BF6 2012-03-05 [expires: 2018-02-02]

Key fingerprint = 44C6 513A 8E4F B3D3 0875 F758 ED44 4FF0 7D8D 0BF6

uid Kali Linux Repository <devel@kali.org> sub 4096R/FC0D0DCB 2012-03-05 [expires: 2018-02-02]

When a third-party package source is added to the sources.list file, APT needs to be told to trust the corresponding GPG authentication key (otherwise it will keep complaining that it can’t ensure the authenticity of the packages coming from that repository). The first step is of course to get the public key. More often than not, the key will be provided as a small text file, which we will call key.asc in the following examples.

To add the key to the trusted keyring, the administrator can run apt-key add < key.asc. An- other way is to use the synaptic graphical interface: its Authentication tab in the Settings

Repositories menu provides the ability to import a key from the key.asc file.

For people who prefer a dedicated application and more details on the trusted keys, it is possible to use gui-apt-key (in the package of the same name), a small graphical user interface that manages the trusted keyring.

Once the appropriate keys are in the keyring, APT will check the signatures before any risky op- eration, so that front-ends will display a warning if asked to install a package whose authenticity can’t be ascertained.

Top OS Cloud Computing at OnWorks: