Secure Email on the Central Email Service

1
Secure Email on the Central Email Service

• Kevin Hobson
• CIT/DCSS

2
I would like to tell you

• What it is and some background info
• What the core components are
• How it works
• Some recommendations

3
Security GoalsWhy do we need secure email?

• Privacy
• Keep information secret from those not authorized
  to see it
• Integrity
• Ensure information is notchanged unknowingly
• Authentication
• Corroborate the source of information
• Non-repudiation
• Prevent denial of a commitment
• Authorization
• Authenticate to prove official sanction to
  perform an action

4
CertificatesAssociating keys with users

• Certificates securely bind the key holders
  identity to their public key
• Contain the users key and identity information
• Name, public key, e-mail, extensions, etc
• Signed by a known and
• trusted entity

5
Secure MIME (S/MIME)

• Uses industry-standard PKIX (X.509 V3)
  certificates
• Implemented by Outlook Express, Netscape,
  Deming, Outlook 98, Outlook 2000, Outlook 8.1
  for Macintosh Netscape, Eudora for the PC, (not
  for the Mac) etc..
• S/MIME compliant clients interoperate
• See http//www.rsa.com/smime/ for
  interoperability test results

6
S/MIME As A Standard

• Initially designed by RSA-led vendor consortium
  in 1995
• S/MIME messaging and S/MIME certificate handling
  are Internet RFCs
• S/MIME V3 is now a proposed standard
• proposed means here that it is already blessed
  by the IETF and is ready for implementation.

7
Exchange Advanced Security Major Components

• Client
• Key Management Server (KMS)
• Certificate Server (CA)
• Exchange Directory

8
Exchange Advanced Security

• Client -
• Enrolls with KMS
• Performs all cryptographic operations on messages
• Key Management Server (KMS)
• Enables clients to participatein Advanced
  Security
• Generates and archives encryption keys
• Cryptography Service Provider (CSP)
• Isolates all KMS crypto
• key generation, database encryption, etc.

9
Key Management Server5.5 Architecture
Microsoft Exchange Server
Directory Service
Encryption certs
Revocation lists
Trust lists
MS Certificate Server
Key Management Service
System attendant
CSP
Policy module
Key archive (encrypted .EDB)
Certification authority
Exchange Admin
10
Key Management Server Key Recovery

• Most valuable feature in KMS
• Archive database - stores keys/certs
• Per-mailbox recovery by KMS admin
• If user loses keys or password
• If user leaves the organization

11
Key Management Server

• Administrator enhancements
• Multiple Password Policies (missile-silo)
• Automated token distribution via e-mail
• Bulk enrollment by recipient container
• Directory - stores certs/preferences
• Client
• Exposes Advanced Security to users
• Reads DS for other users certificates
• Performs all cryptography onmail messages
• Protects private keys in secure store

12
Certificate Authority

• A CA is a known and trusted third party which
  issues certificates
• CAs Private key used to sign certs
• Root CA certificate needed to verify sigs

13
MS Certificate Server

• Microsoft Certificate Server becomes the
  certificate authority (CA) for KMS
• Put another way KMS provideskey-recovery for
  Certificate Server
• The KMS is the Registration Authority (RA)
• Issues X.509 V3 certificates
• Issues X.509 V3 CRLs

14
MS Certificate Server (cont.)

• We have implemented our CA as a root CA.
  Subordination is possible at a later time.
• Our implementation requires installation of the
  Exchange policy module. Locks down the CA for
  Exchange Organization use only.

15
Chain of Trust

• We could have other CAs (external or internal to
  NIH) trust us
• This allows for a chain of trust that would
  make it easier for an NIMH user to send and
  receive secure email from someone in the FDA
• This is a significant policy decision that has
  not been made.

16
Certificate trust lists (CTLs)

• External CA certificates imported through the
  administrator
• These certificates are added to a signed CTL and
  thus are trusted
• CTLs are stored in the directory andin the
  client-secure certificate store
• Certificates in a CTL can be untrusted at a later
  time

17
CertificatesMore about trust

• Certificates can be explicitly trusted
• A client app can import a cert to be trusted
• Clients and CAs can maintain a list of
  explicitly trusted certificates
• Clients and CAs can create anon-hierarchical
  ring of trust
• Certificates can be explicitly distrusted
• Place certificates on a CRLCertificate
  Revocation List
• Certificates can expire

18
The Exchange Directory

• The Exchange Directory holds the certs of
  enrolled users
• CTLs are stored in the directory andin the
  client-secure certificate store
• The KMS publishes the certs to the Directory.
• The Directory can expose certs via LDAP making
  them available to POP3 and IMAP clients so enabled

19
Client Enrollment

• Request a security token from Administrator
• Tools / Options / Security
• Get Digital Id
• Choose Exchange Server Security
• Enter Token
• Install Certificate
• Review Cert under /Tools / Options / Security

20
Enrollment Walkthrough

• Administrator issues token and sends to user
• User enters token in client and generates
  enrollment request
• Client sends encrypted request to KMS

21
Enrollment cont

• KMS generates encryption key pair
• KMS sends both to MS CS and gets certificate back
• KMS sends RC2-128 encrypted response to user

22
Key / Certificate Storage

• My Certs Windows registry
• Private Key password store (pstore)
• Other Peoples Certs Contacts, Address Book,
  Exchange Directory
• Root CA Certs Windows Registry

23
My Key/Certificate Storage

• Keys must be stored in locationknown by client
• Common protected store - shared byOE, Internet
  Explorer, Outlook
• The same certificates and key sets must be on
  each machine you use to read encrypted messages
• Certificates can be imported/exported

24
Storing Certificates from Outside the NIH Org.

• S/MIME certificates passed alongwith e-mail
  message
• Add sender to Address Book/Contacts
• This is what the KMS does for us within the Org.
  it publishes the certs to the Directory so we do
  not have to perform this manual process

25
Client Security

• Once a client is enrolled, he/she can
• Send/receive signed mail
• Receive encrypted mail
• Send encrypted mail to enrolled recipients
• Have KMS admins recover theirkey when they
  require it (like when they forget their password)

26
Possible Issues for ITMC Comment

• IC Management review of Certificate Request?
• What should be encrypted?
• What should the client default setting be?
  (always send signed or not?)
• Key Escrow Policies ???
• Key Recovery
• Who
• Under what Conditions?

27
Implementation Timeframe

• The server side components are production now.
• CIT will be ready to support the client side
  within 30 days.
• Setting up INTER-site connectivity is trivial
  30 seconds
• An ICs implementation is up to the IC.
• We will NOT export tokens without permission

28
Recommendations

• Begin a Pilot immediately
• (there is a token in your inbox waiting for you
  right now! (well, if possible))
• Determine who needs it - or not
• Test with your ICs clients
• Including cert. Import/export
• Educate your users
• EX recommend they NOT set as the default..
• Deploy across your entire Exchange site all at
  once or by group or by person (within reason)

29
Future Directions

• WIN2K major implementation of certificate-based
  security and directory services
• Further integration of certificate stores into
  the Exchange Directory and WIN2K Active
  Directory Service

30
Closing Message

• This solution delivers an interoperable and
  flexible public key infrastructure for
  participants in the NIH Exchange Organization
• S/MIME is a proposed/implemented standard in the
  IETF that provides interoperable secure email
• Flexible trust topology with other CAs
• It is available now
• This implementation has the least impact on our
  users.