This proposed patch results from a security review of the Firebird SRP-6a implementation taking into account current NIST guidance on the use of SHA-1 - see NIST Special Publication 800-131A, Revision 1, Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths (http://dx.doi.org/10.6028/NIST.SP.800-131Ar1
) chapter 9. This guidance disallows the general use of SHA-1 for "Digital Signature Generation" whilst permitting continued use for "Digital Signature Verification".
Review of the Firebird SRP implementation appears to indicate that most uses of SHA-1 continue to be permitted under NIST guidance except for its use in generating the client proof. The SRP client proof may be characterised as a "Poor Man's Digital Signature" in that it provides a two party proof of identity rather than the third party proof normally expected from a Digital Signature i.e. it is not a non-repudiable proof. Nevertheless, it is believed that generation of the client proof falls under the heading of "Digital Signature Generation" when considering the NIST Guidance.
Continued use of SHA-1 in order to generate the client proof appears to risk leakage of the shared session key used to encrypt "over-the-wire" encryption and which hence also provides peer entity authentication during the lifetime of the connection. This may result in an attacker being able to monitor confidential communication either during the connection or at some later date and this could include leakage of an encryption key used to encrypt the user database, if this is passed from client to server during the connection.
Such an attack is viable if weaknesses in SHA-1 can be exploited to allow a brute force attack on the client proof to be computationally feasible. All parts of the message on which the client proof is based may be known to an attacker with the exception of the shared session key and such an attack would concentrate on revealing this key. If it were possible to reveal the shared session key in real time then additionally a man-in-the-middle attack would be feasible.
The severity of this issue is viewed as Important but not Critical. This is because (a) users that comply with NIST Guidance as a matter of policy may feel unable to use Firebird/SRP and hence choose or migrate to a different database, and (b) users that rely on SRP/over the wire encryption to protect confidential communication have a long term risk that the confidentiality of their data may be compromised. The attack may also be mitigated through the use of other procedures to protect communications (e.g. a secure VPN).
The patch adds a new directory to the source code tree (src/common/sha2) containing an implementation of the SHA-2 family of message digests derived from the implementation published by Olivier Gay <email@example.com
> (see https://github.com/ouah/sha2)
. This has been adapted for Firebird as a set of classes that follow the model of the existing Firebird::Sha1 class. Classes are provided for SHA-224, SHA-256, SHA-384 and SHA-512. A SHA-2 compliancy confidence test is also included.
The SRP RemotePassword class is modified to additionally include a method for generating a client proof using SHA-256 as the message hash.
The SRP client class is modified to use only SHA-256 for generating the client proof.
The SRP server class is modified to use either SHA-1 or SHA-256 for verifying the client proof, with the verification method depending on the length of the client proof. This is believed to be compliant with NIST Guidance for legacy use of SHA-1 and permits backwards compatibility with older clients.
The patch also modifies the makefiles for posix builds in order to include the SHA-2 classes in the "common" library and has been tested on Linux. It may be necessary to modify the build procedures for other platforms in order to use the patch.
It is proposed that this patch is expedited into the next step release of Firebird 3 and which should be made available as soon as possible.