# Presentation: 148707

## Secure Email on the Central Email Service

**Kevin Hobson**
**CIT/DCSS**

## I would like to tell you:

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

**Notes:**
Motivations...  why do we have the tools?

Privacy - “secrecy”

Integrity - 

Origin Authentication -

Non-repudiation -

Authorization - validation/access control

Many others - time-stamping, receipt confirmation.

## Security GoalsWhy do we need secure email?

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

**Notes:**
Motivations...  why do we have the tools?

Privacy - “secrecy”

Integrity - 

Origin Authentication -

Non-repudiation -

Authorization - validation/access control

Many others - time-stamping, receipt confirmation.

## CertificatesAssociating keys with users

**Certificates securely bind the key holder’s identity to their public key**
**Contain the user’s key and ****identity information:**
**Name, public key, ****e-mail, extensions, etc... **
**Signed by a ****known ****and**
***	*****trusted***** *****entity**

**Notes:**
Certificates
   Digital documents 
   Bind a public key to an individual’s identity
SIMPLE CERTS CONTAIN: 
   Public Key and Name
COMMON PRACTICE CERTS CONTAIN:
   Expiration date, Name of the CA that issued, serial number
X.509
   Extensions are now a part of certificates.  Sign/seal
   Most importantly, it contains the digital signature of the
   certificate issuer.
   CA investigation

## Secure MIME (S/MIME)

**Uses industry-standard PKIX (X.509 V3) certificates**
**Implemented by OutlookTM Express, NetscapeTM, Deming, OutlookTM 98, OutlookTM 2000, OutlookTM 8.1 for MacintoshTM 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**

## S/MIME As A Standard

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

## Exchange Advanced Security – Major Components	

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

## Exchange Advanced Security

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

## Key Management Server5.5 Architecture

**Key Management Server****5.5 Architecture**

**Microsoft Exchange Server**

**Directory Service**

**Key Management Service**

**Key archive (encrypted .EDB)**

**Encryption**
**certs**

**Exchange Admin**

**Revocation lists**

**CSP**

**Trust lists**

**MS Certificate Server**

**Certification**
**authority**

**Policy**
**module**

**System**
**attendant**

**Notes:**
CSP = Cryptographic Service Providor

## 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**

## 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 user’s certificates**
**Performs all cryptography on****mail messages**
**Protects private keys in secure store**

## Certificate Authority

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

**Notes:**
Explain Known and Trusted

No global PKI, so trust is the hardest issue

Mail scenario

                                     Dir
Sender                                                      Recipient

                                       CA

## MS Certificate Server

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

## 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.**

## 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.  **

## 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 and****in the client-secure certificate store**
**Certificates in a CTL can be untrusted at a later time**

## CertificatesMore about trust... 

**Certificates can be explicitly trusted**
**A client app can import a cert to be trusted**
**Clients and CA’s can maintain a list of explicitly trusted certificates**
**Clients and CA’s can create a****non-hierarchical ring of trust**
**Certificates can be explicitly *****dis*****trusted**
**Place certificates on a CRL*****Certificate Revocation List***
**Certificates can expire**

## The Exchange Directory

**The Exchange Directory holds the cert’s of enrolled users**
**CTLs are stored in the directory and****in 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**

## 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**

## Enrollment Walkthrough

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

## Enrollment con’t

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

## Key / Certificate Storage 

**My Certs – Windows registry**
**Private Key – password store (pstore)**
**Other People’s Certs – Contacts, Address Book, Exchange Directory**
**Root CA Certs – Windows Registry**

## My Key/Certificate Storage

**Keys must be stored in location****known by client**
**Common protected store - shared by****OE, 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**

## Storing Certificates from Outside the NIH Org. 

**S/MIME certificates passed along****with 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...**

## 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 their****key when they require it (like when they forget their password)**

## 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?**

## 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 IC’s implementation is up to the IC.**
**We will NOT export tokens without permission**

**Notes:**
resolving the interoperability issues between Outlook Mac and Outlook Windows
developing methods to distribute tokens, particularly to Outlook Express and Eudora clients
defining the supported client matrix
documenting the process for using secure email from more than one client (the Clinical Center could have some issues here with roaming users)
developing end-user documentation, including recommendations for when and when not to use encrypted and/or digitally signed email

## 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 IC’s 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)**

## 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**

## 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 CA’s**
**It is available now**
**This implementation has the least impact on our users.**