During the internal code review, it was discovered that Red Hat Certificate System / Dogtag Certificate System does not properly verify challenge response received during the enrollment of new security token. If keys are generated on the token during the enrollment, TPS correctly verifies that the requestor possesses the private key, but fails to verify that the key really exists on the token and is not only in software. An attacker with access to blank token known to TPS component and with privilege to perform enrollments of new tokens could use this flaw to successfully finish enrollment procedure with the software generated key instead of the one stored in the token. Affected versions: Red Hat Certificate System 7.1, 7.2, 7.3 Dogtag Certificate System 1.0
Further details from Christina Fu and Bob Relyea: This issue affects only enrollments involving keys generated on the tokens. When keys are generated on the tokens, TPS has the responsibility to make sure that the following 2 conditions are met: a. The caller indeed possesses the private key b. The private key indeed exists on the token To guarantee both conditions, a random 16 byte data (challenge) is generated on the server side encrypted with a shared secret (Key Encryption Key) between the token and the server. The token, upon receiving the encrypted data, decrypts the data with the same secret known to only the token and the server, and signs the data with it's private key and sends the signed data along with it's public key to the server for enrollment. When the server (TPS) receives this enrollment request, it calls the verifyProof() function, which verifies the signature of the signed data against the challenge. The (a bit simplified) description of the process tells us that: 1. The fact that the token is able to decrypt the challenge proves that the server is talking to a known token. 2. The fact that the signed challenge verifies proves that the caller indeed possesses the private key matching the public key submitted for enrollment. This flaw is within the verifyProof() function itself. In case of some failures, it sets the ReturnValue's statusNum, but forgets to set its status to PR_FAILURE. As a result, it always returns success (the default). This flaw potentially downgrades what hardware token can provide for you to the security grade level of a software token. Real effect of the flaw depends on the way TPS is used in specific deployment. It can be used in the officer mode, when only privileged (and trusted) security officer is allowed to enroll new tokens. This issue may have greater impact in deployments where individual users are allowed to enroll their tokens via ESC (Enterprise Security Client).
Lifting embargo.
This issue was addressed in: Red Hat Certificate System: http://rhn.redhat.com/errata/RHSA-2009-0007.html Note: It is currently not planned to address this issue in Red Hat Certificate System 7.1 and 7.2.