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

[Andreas Kuehne <kuehne@trustable.de>]

Hi Timothy !

>  Here's what I think are necessary:
I agree with all your precautions. All this should be taken into account 
when designing a real implementation. But I wouldn't like to see a mix 
of concerns between DSS spec and implementation details.

E.g. there are many efforts out there that care about authentication. I 
don't believe we could design a better authentication solution 'en 
passant' . So let's concentrate on our primary goal and leave the rest 
to other experts !


>  - 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.
I don't like signing a hash and the German-Sig-Law-Profile prohibits 
it's use at all.

But except within an odd PKCS7 mode there is always a second stage of 
hashing involved. So the hash as it is usually don't serves as the input 
to the encryption step.

>  - 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.
I don't think we could cover all DSS usage scenarios even roughly. It 
spans from simple intranet transport protection to legally binding 
signatures.
The security aspects are very domain-specific and dtmo should be 
targeted there, not by the general DSS.

Greetings

Andreas K.


___________________________________________________
Andreas Kühne
phone: +49 177 293 24 97
mailto: kuehne@trustable.de


Trustable Ltd.
Niederlassung Deutschland
Ströverstr. 18 - 59427 Unna
Amtsgericht Hamm HRB 5868

Directors
Andreas Kühne
Heiko Veit

Company UK
Company No: 5218868
Registered in England and Wales