Experimenting with ServerAided Signatures

1
Experimenting with Server-Aided Signatures
Xuhua Ding, Daniele Mazzocchi, Gene
Tsudik ICS Department, UC Irvine
http//sconce.ics.uci.edu/sucses
2
Outline

• Motivation
• SAS Protocol Description
• SAS Protocol Analysis
• Related Work and Summary

3
Motivation

• Not enough computation power in smart portable
  devices like hand-helds, cell phones, to perform
  full-blown crypto operations
• Access to infrastructure is often available,
  .e.g., cell phone and base station, smartcard and
  smartcard reader
• End-user/device signs a document off-line,
  verifier(s) later needs to check if signers PK
  valid at signature time.
• E.g., email (store-and-forward) what if
  senders PK revoked by the time receiver reads
  email?
• GOAL off-load computation and obtain
  finer-grained revocation

4
Basic Idea Using SEcurity Mediator
SEM
SEM
5
SAS Protocol Setup

• Let dn be Alices private key (chosen at random)
• n max of signatures, chain length
• Alice computes d0 h(h(h(dn))) hn(dn)
• Keeps dn secret
• Obtains PK cert from CA containing
• CERTALICE
• Alice, n, h, SEM, d0 ,start/end-time, etc.,CA

6
SAS Protocol Sign

• To sign i-th message M
• Alice asks SEM to help sign M h(M), i, di
  
• If Alice not revoked SEM responds S M
  SEM
• Alice verifies S (inexpensive!)
• Alices signature
• S CERTALICE , CERTSEM, M, S, di1

7
SAS Protocol Verify

• To verify
• LIGHT VERIFICATION
• Bob verifies S (plain RSA) and CERTSEM
• Checks that di h(di1)
• FULL VERIFICATION
• Same as LIGHT, plus
• Verify CERTALICE
• Check that hi(di)d0

8
How SAS works
SEM
Alice
CA
dn
SEM
i, CERTALICE
i, CERTALICE
M,S,i
Bob
SEM must keep state!
9
Outline

• Motivation
• SAS Protocol Description
• SAS Protocol Analysis
• Related Work and Summary

10
Notable Features

• SAS Invariant
• For a given SAS certificate, at most one
  signature is created (by SEM) for each i, di

• Binding Signature Semantic
• At time T of signature computation, Alices SAS
  certificate was believed by SEM not to be revoked

11
Notes

• Security equivalent to underlying signature
  scheme
• SEM communication not authenticated or secret
• SEM cannot be used as oracle
• Denial of Service attack on SEM is not a concern
• SEM is not a TTP
• SEM load lt OCSP Validation Agent load

12
Issues/Problems

• What if SEM is compromised?
• Cannot obtain users secrets
• Can sign i times on behalf of user but user will
  prevail in the end!
• SEM in collusion with user ? cannot revoke user
• Fail-stop feature SEM can be exploited by
  attacker but only ONCE per user. Can use
  authenticated channels.
• Complete user compromise is detectable and damage
  is limited.

13
Efficiency

• Network overhead
• RTT between User and SEM
• SEM computation
• message signing. Expensive for RSA
• User computation
• hash operation and verification, cheap for RSA

14
Performance (SEM on 933 PIII, OpenSSL)
RSA
SAS
15
Software

• SAS Available in
• Openssl-style library or
• as a Eudora plug-in (sender and receiver)
• plus stand-alone verifier program (works with any
  mailer, acts a new mime-type viewer)

16
SW SAS plug-in (Eudora)
17
SW SAS verifier (Eudora)
18
SW SAS verifier (Netscape)
19
Summary

• Fine-grained Revocation
• New signature type
• Alternative / Complement to CRLs
• Easy secure time-stamping by SEM ? signature
  causality
• Good fit for email
• No performance penalty ? speedup for weak
  devices!!!
• Built-in compromise detection
• Built-in SEM attack resistance

20
History and Related Work

• SAS first appeared in Asokan et al. 1997
• Just concepts, no design or implementation
• Related to mRSA Usenix-Sec2001, Yaksha
  Ganesan and Reiter/McKenzie SP2001

21
Pointers
SUCSES web page sconce.ics.uci.edu/sucses
22
SUCSES Architecture
SEM daemon
Revoke/Add
Alice
Key Bundles, certs, etc.