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

["Pope, Nick" <Nick.Pope@thales-esecurity.com>]

Tim,

I agree this could be appropriate regarding implementation guidance.  I
suggest that DSS-X consider this as input to the maintenance process.

Nick

> -----Original Message-----
> From: Timothy J. Miller [mailto:tmiller@mitre.org]
> Sent: 03 July 2007 20:01
> To: Pope, Nick
> Cc: dss-comment@lists.oasis-open.org
> Subject: Re: [dss-comment] DSS as a encryption/decryption oracle.
> 
> 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