Currently it is common that software packages are cryptographically signed using methods of public-key cryptography. Software vendor signs package using his private key and signed software package is then distributed along with vendor’s public key. This vendor’s public key can later be used in automatic software update verification process.
The current method is of limited use when user of a computer system decides to install software package for the first time. Because this is the first installation, there is no information about correct vendor’s public key, so it is up to the user to verify authenticity of the software by some other means. Typically this verification requires some level of technical skills and some time investment, so users often decide to skip the verification. This leads to dangerous situations where users are installing software from various sources, which were not verified, and thus the users are undertaking risk of installing maliciously modified version of the software.
The second limitation of the current method is related to risks of key compromise. It might happen that the software vendor lost access to the private key used for signing software packages, or that his private key was stolen, or misused e.g. by one of vendor’s employees. These situations are hard to handle with current model because the private key cannot be trusted anymore. This is a problem because all the security of software update chain is depending on compromised key, so there is no way for the vendor to securely handle these cases.
DNS is a decentralized and distributed database capable of storing various types of data. It is common, that an entity (such as company) owns a domain name related to the name of the entity. This entity has usually full control over the data published under its domain name and sub-domains. DNSSEC is a mechanism enabling clients to verify the integrity and authenticity of DNS responses. It is using an asymmetric cryptography and provides an independent chain-of-trust using which an entity owning a DNS domain can publish any record on the Internet and a client can obtain this data and verify its integrity and authenticity.
- Make yourself familiar with DNS protocol basics
- DNSSEC extension of DNS protocol
- DANE (RFC 6394)
- CERT Resource Record (RFC 4398)
- OPENPGPKEY Resource Record (RFC 7929)
- Make yourself familiar with public-key cryptography.
- Analyze the current way a software packages (RPM) are signed and verified in a Linux distribution (Fedora) by the package manager (DNF).
- Analyze the format of metadata (possibly X.509 certificate) used for storing public key in software packages (RPM).
- Analyze the possibility of using DNS and some already standardized DNS Resource Record for storing necessary metadata for automatic verification of software packages (RPM) signature verification.
- Design a solution which will store a suitable data in DNS database and use this data to verify a public key authenticity, which can be then used for verifying signatures of software packages (RPM). The solution should contain:
- Definition of a process, or a set of processes, for transforming the name of the entity owning the public key to a DNS domain name, which can be queried for information needed to verify or ban the public key.
- Ability to verify authenticity of key used by software vendor to sign a software package.
- Ability to distribute information about key revocation.
- Ability to distribute information about revoking particular signatures made by particular signing key (to mitigate impact of limited key misuse without need to revoke the key completely)
- Implement your solution possibly as a plugin of Fedora package manager (DNF) or integrated it directly with the package manager. The solution should be able to:
- Automatically verify a new public key used for verifying a software package signature and inform the user about this fact.
- Automatically ban a public key from being used, in case it has been revoked and do this even for key that had been trusted in the past. Inform the user about this fact.
- Reject an individual package signature, if it was revoked.
- Fall back to the “old” way of asking user to verify the public key being used, in case of some technical difficulties (Internet not available, DNSSEC can not be used to verify the integrity and authenticity of a DNS response).