Re: [dss-comment] DSS as a encryption/decryption oracle.

["Timothy J. Miller" <tmiller@mitre.org>]

On Jul 3, 2007, at 11:48 AM, Pope, Nick wrote:

> Are you talking here about an attack on use for DSS for encryption /
> decryption or for signing?

Signing.

> If this relates to signatures then the signing will only be invoked by
> authorised individuals and so will not be subject to external attack.

Nothing stops an authorized person from attacking the service.  Also,  
since the general implication is that DSS users generally lack strong  
authentication (otherwise they could sign it themselves), it is  
possible that an unauthorized user has gained access to an authorized  
user's credentials.

The protocol itself needs protection against these kinds of attacks.   
See RFC3218, "Preventing the Million Message Attack on Cryptographic  
Message Syntax," for an example of what I mean.

Here's what I think are necessary:

- The service must implement signature schemes that are provably  
secure against both chosen-plaintext and chosen-ciphertext attacks.

- The service must not allow unauthenticated signing operations. This  
impedes the ability of any attacker to use the service as an oracle.

- The service must sign only objects, not hashes of objects. This  
impedes an insider's ability to utilize the service as an oracle.

- The service must implement detection and prevention of misuse. This  
impedes the use of the service as an oracle, and provides support for  
denial-of-service protection. However, as the "normal" volume of the  
service increases, the ability to detect misuse decreases.

- The service must utilize hardware security modules for private key  
operations. This supports service non-repudiation.

- The service must implement some form of authority delegation. This  
provides support for attribution and non-repudiation.

If nothing else this should be covered in implementation guidance, as  
security considerations, which appear to be missing from the standard.

-- Tim

smime.p7s