Public Key Infrastructure for a Higher Education Environment

Transcription

1 Public Key Infrastructure for a Higher Education Environment Eric Madden and Michael Jeffers 12/14/2001 Written for ECE 646, Professor Gaj

2 Table Of Contents Table Of Contents...2 List of Figures...3 List of Tables...3 Abstract Introduction University Stakeholders Security Infrastructure Root Certificate Authority Subordinate Certificate Authority University Hierarchy Certificate Repository Securing the Certificate Authority and Certificate Repository Servers Key Management Key Expiration Key Size Key Registration Key Renewal Certificate Revocation Client Software Private Key Store Windows 2000 Implementations Setup a Certificate Authority Model Root Certificate Authority Server Certificate Repository Server Certificate Template Setup Trust for the CA Certificate Repository Renewal, Revocation, and Publishing a Certificate Revocation List Active Directory Windows 2000 Applications Secure Smart Cards Authentication Secure Web Communications and Sites IPSec Encryption File System PKI Application Program Interface Windows 2000 Supported Cryptographic Algorithms...18 Summary...19 References...20 Acronyms

3 List of Figures FIGURE 1 FIGURE 2 University Certificate Authority Hierarchy Projected Model Repository Server, Certificate Authority and End Entity Interactions List of Tables TABLE 1 TABLE 2 General Hardware Configuration Guidelines for Certificate Services Windows 2000 Enterprise Supported Applications 3 3

4 Abstract This is an analysis of the security requirements and needs for a University security system. The analysis will include a listing of stakeholders and their security requirements with regards to legal and commercial criteria. Each component of the analysis will consist of a description and recommendation for each component of the structure. 4 4

5 1 Introduction A University computer infrastructure is heterogeneous system with a diverse set of requirements and needs. The University security needs and requirements are just as diverse. A University Professor working on a government research grant for a defense or intelligence agency has a different set of security requirements than an employee working in the financial office dealing with loans or that of a student looking to register for a class. The University s security infrastructure must be able to support whichever possibility. The security infrastructure must take into account each stakeholders need and match it to a solution, which delivers the proper security and functionality. It must be matched to the user and not the user being forced into one solution. 1.1 University Stakeholders The University has several stakeholders hose needs must be addressed in the development of a security policy. Faculty, Faculty is the professors and instructors at the university. The faculty may require secure transmission and/or applications. They interact with individuals around the world as well as students locally. Administration, Administrators are the employees of the University, which perform the supporting roles in the functioning at the University. This could include finance and loans, the registry s office or the running of the bookstore. Business Interest, Business interests are those having input and contact to the University through grants, gifts and donations. They could include companies providing money for Suppliers, Suppliers are outside venders who provide products to the University and may require access to communicate, check inventory and bid on contracts. Students, Students will require network access but to a degree that is deemed appropriate and not too intrusive. Does a student require multilevel login and authentication to read their or access an Internet workstation? Local/State Government, Education is principally a state funded endeavor. With that funding the state will oversee the institution with regulations and policies. Federal Government, The Federal government is also a stakeholder by extending loans/scholarships to students. The federal government could also institute research grants and projects that will add an additional burden on the institution. If for example a research grant provided by the Department of Defense will require security on top of what the University will require for other sources. The stakeholders each have a unique connection with the University as they try to access the University s data, resources and/or applications. These stakeholders can be trusted heterogeneously with an implementation of Public Key Infrastructure (PKI). With the implementation of a hierarchical model to distribute and disseminate trust through the structure would provide stakeholder the ability to access the needs without jeopardizing their security requirements. PKI provides a generic security infrastructure that will provide security services for a range of unrelated applications and services. Industry PKI solutions are principally a hybrid system. The PKI is used for key exchange of secret keys as well as the expected signatures. A PKI solution should provide certificate creation, validation, digital signatures, key and certificate management and timestamp services. The PKI environment should be able to support multiple applications. 5 5

6 Public-key systems depend on the mathematical relationship between the public and private keys. It's not feasible to derive one from the other. There are two fundamental operations associated with public key cryptography: encryption and signing. The goal of encryption is to obscure data in such a way that it can only be read by the intended party. The University can make use of this encryption technology by using PKI. It has been found from comprehensive researching that Windows 2000 Advanced Server has a secure PKI infrastructure out-of-the box design. 2 Security Infrastructure The Benefit of a PKI implementation is that the user can have a secure sign on. The user will authenticate against the infrastructure at the point of connection and be able to use the applications within the infrastructure. The University must develop a diverse set of requirements for the establishment of a PKI for its security foundation. The PKI design will run on a distributed key environment. This will enable a distributed environment allowing each certificate authority (CA) the ability to control its domain. A PKI certificate hierarchy will be established with the central root certificate authority and subordinate certificate authority. 2.1 Root Certificate Authority A root certificate authority (CA) will be established, which will be trusted by an outside third party. The role of the root certificate authority is to establish and maintain the keys for the subordinate certificate authorities. Once created the root certificate authority should renew a subordinate certificate authority once a year. 2.2 Subordinate Certificate Authority The primary role of the subordinate CA is to create keys and binding them to the subject by proof of its identity. The process the subject acquires a key is through the process of registration. The CA is also responsible for the maintenance of the key through key management. 2.3 University Hierarchy The certificate hierarchy will be based on the colleges, support service Finance and Administration of the University as seen in Figure 1. Figure 1, University Certificate Authority Hierarchy Projected Model Root Certificate Authority College of Business College of the Arts Finance College of Sciences College of Agriculture College of Engineering Administration Support Services 6 6

7 The model will use the inherent nature and structure of the University by establishing a CA in each college of the University. The Support Services, which include library, bookstore, custodial, etc. services will also make up there own subordinate CA. Finance and the Administration will also be drawn out to reflect their special needs and security requirements. The finance division may want a more restrictive environment than the College of the Arts or the administration division may not want the other areas of the model looking into their area. Each respective certificate authority will then certify each user and non-user. Students and faculty will certify by their college within the University. The use of the hierarchical structure will also provide a security flexibility that each CA can tailor there policy to reflect the needs of its domain while maintaining the University overall security policy. 2.4 Certificate Repository The role of the certificate repository is to hold the certificates and Certificate Revocation Lists (CRL). It is a library of certificates available where users, servers and processes can verify the subject. By having the repository separate from the Certificate authority the CA can concentrate on the process of key creation. Also the security repository can allow the certificate authority to go off-line in periods of low activity for added security. The repository becomes point of contact for key resources. The certificate repository can be a directory service, including X.509, the Lightweight Directory Access Protocol (LDAP), operating system specific directories or FTP/Web Servers. The process by which the Repository server interacts with both the End Entity and the CAs is seen in Figure 2. The End Entity can request a certificate to the subordinate CA which if approved would generate the key pair. The CA will provide the private key to the end Entity. The Public key will be published to the Repository Server where it will become available to other entities. Figure 2, Repository Server, Certificate Authority and End Entity Interactions 7 7

8 2.5 Securing the Certificate Authority and Certificate Repository Servers The servers must be kept safe and secure. If these systems are compromised then the entire infrastructure will be open to exploitation. The systems the servers are running on should be locked down to prevent unauthorized access. Operating systems should have the most recent patch and hardened. Only required access and applications should be available to these systems. No users should be able to gain remote access to these servers. An added security feature would be if the CA server could be off-line until needed. The CA will be secure if it is unavailable. This protection also includes the physical space and power supply. Periodic backups should be performed and that media properly secured in an on-site and off-site location. The repository server requires additional protection since it is a single point of failure to the users, applications and system resources of the University. If the Certificate Repository is not available then the University does not function. These systems should be ensured ongoing operations by the additional requirements such as RAIDs and ghost servers. Also these servers should be tied into the network with dual NICs attached to two unique network points to ensure network redundancy. The Certificate Repository server must have both system and network redundancy. 2.6 Key Management Public keys are required for PKI-based security. The private key is never shared, so it doesn t require packaging, it s simply stored securely with each user to the PKI system. The certificate contains the public key and a set of attributes, like the key holder's name. These attributes may be related to the holder's identity, what they're allowed to do, or under what conditions the certificate is valid. The binding between attributes and the public key is present because the certificate is digitally signed by the entity that issued it; the issuer's signature on the certificate vouches for its authenticity and correctness. The key management will reflect the University s security policy. The policy will be developed and implemented to provide the University community with a secure infrastructure Key Expiration Keys generated by the University PKI will have a life of 12 months from its creation. This provides the University a window of keys that is conducive to their environment of the school year. CAs will have a certificate life span of 24 months Key Size To ensure proper security for all subjects in the corporate infrastructure the key size for subjects will be 1024 bits and certificate authority keys will be 4096 bits. This allows a security for the user without severe degradation in availability and performance. It provides the server with added security required for some of its more vulnerable processes Key Registration Key registration will take place at the college level in the university. Select trusted users within the infrastructure initialize this process. There are two processes to acquire a certificate, a user and a non-user. A user is an actual human being while the non-user can be a server, printer, workstation, etc. To register for a new user certificate An individual pre-selected in the department within the College will initiate the process. The individual will input the user information based on the following x.509 format. 8 8

9 Country, C= United States Organization, O= University Name Organizational Unit, OU= College Name Organizational Unit 2, OU2= Department Name Certificate Name, CN= User Name Once the information is inputted it is forwarded to the Dean of the College or designated individual in the organization to approve the certificate request to the CA. The process provides a separation of duty, which will without collusion, provide for a valid proof of identity for the generation of a certificate. To register a new non-user certificate The owner of the system will provide the information and function of the system requiring a certificate. The owner will fill out the request on the CA registration web site with the following x.509 format. Country, C= United States Organization, O= University Name Organizational Unit, OU= College Name Organizational Unit 2, OU2= Department Name Certificate Name, CN= System Name Once the information is inputted it is forwarded to the Dean of the College or designated individual in the organization to approve the certificate request to the CA. The process provides a separation of duty, which will, without collusion, provide for a valid proof of identity for the generation of a certificate. Once the Dean signs off on the certificate, the request is forwarded to the CA for processing Key Renewal Once the subject has a certificate it will periodically require renewal to maintain its validity. The process for renewal is one of two processes dependent on whether the subject is a user or nonuser. To register for a current user certificate The user with a certificate will renew their certificate on-line. s should be periodically sent to the user as a reminder of the expiring certificate. The user should then re-certify their personal information on line. Once the Dean approves the request for renewal it would be forwarded to the CA and processed To register a non-user certificate The owner of the system with a certificate will renew their certificate on-line. s should be periodically sent to the owner as a reminder of the expiring certificate. The owner should then recertify their system information on line. Once the Dean approves the request for renewal it would be forwarded to the CA and processed. Once the key is generated it should be returned to the owner Certificate Revocation Prior to the expiration of the certificate a certificate may need to be revoked. This can be caused by a student graduation, a member of the staff leaving the University or a web server being moved to another IP address. In the event a certificate is being revoked the certificate authority must be notified to place the revoked certificate on a Certificate Revocation List (CRL) 9 9

10 The Security Officer should be provided a list of all employees leaving the University. Once this list is provided the Security Officer will revoke certificates at the respective certificate authority and produce a CRL. The will be periods of time where there will be a lot of revocations due to the transitional nature of the University environment. During this period if additional help is required the additional revokers should be trusted individuals. Throughout the year and normal operations the CRL should be replicated once per day. The CRL will have the ability to force replication in severe cases of revocation Client Software Private Key Store The subject s private key once received should be protected. The user(s) within the system shall be responsible for maintaining the integrity of the subject s key(s). Encrypting the key on the system best does this. In the case of a user the key should require a password to unlock the key store. In future University PKI implementations the key could be kept on a smart card. The client software should also be able to implement a policy management service to the desktop. The policy information will provide membership and role based information. 3 Windows 2000 Implementations The University must develop a diverse set of requirements for the establishment of a PKI for its security foundation. The PKI design will run on a distributed key environment. This will enable a distributed environment allowing each certificate authority (CA) the ability to control its domain. A PKI certificate hierarchy will be established with the central root certificate authority and other local root certificate authorities. PKI will be used with a University to establish a secure transaction environment. The Windows 2000 Advanced Server operating system is the product of choice that includes a native PKI that is designed from the ground up, out-of-the box, to take full advantage of the Windows 2000 security architecture. This paper describes the features of public-key security systems. It also describes how the Windows 2000 PKI components deliver needed services while providing interoperability, security, flexibility, and ease-of-use. The primary components within the Windows 2000 operating system PKI are: Certificate Services, a core operating system service that allows the university to act as their own third party CAs and issue and manage digital certificates. Active Directory Service, a core operating system service that provides a single place to find network resources; it serves as the publication service in the PKI. PKI-enabled applications like Internet Explorer, Internet Information Server, Outlook, and Outlook Express, as well as myriad third-party applications that work with windows 2000 PKI. Exchange Key Management Service (KMS), a component of Microsoft Exchange that allows for the archiving and retrieval of keys used to encrypt . In a future version of Windows, the KMS will become subsumed into the Windows operating system as an enterprise-wide KMS. It is not secure to accept a root CA s assertion of its own identity. Microsoft provides the public keys for many popular root CAs in PKI-enabled products like Internet Explorer and Netscape. Root CAs can also provide copies of their public keys for downloading from public web sites. Once the root key has been delivered via an out-of-band means, the user can verify the root certificate, and hence the entire certificate chain. Also, because each certificate s digital signature protects it from tampering, certificate chains can be freely passed over insecure media like the Internet. Five pieces that make up a complete PKI; these components create, validate, transport, and use the digital certificates that the PKI depends

11 3.1 Setup a Certificate Authority Model Implementation of the PKI using CAs shall be configured as followed. In implementing PKI, first review the high-level network layout for the college, decide on what domains need to have PKI setup using certificate authorities. For the college s PKI, the enterprise CA model chose to use. The enterprise CA model shall be used to control users for internal resources with no outside third-party vendors for certificate authority. Generation of the certificates shall be made from the enterprise CA model using the Certificate Services components. The Certificate Services component can be added to the server by going to the Add/Remove Programs within the Windows 2000 server. The Certificate Services are the core operating system service that allows the college to act as their own Root CAs. The Certificate Services uses Windows 2000 local storage for its database, configuration files, backup files, and log file used for auditing of the system. The default location for Certificate Services files, shall be systemroot/system32/certlog. The Certificate Services adds the following components that shall be used by the Root CA s administration person: Certification Authority - Which is a console for admin managing CAs. Certificates - Which is a snap-in that shall be added to MMC Microsoft Managing Console. Certificate Services Web enrollment support - Web Page provided for all user within the CA realm to request certificates Root Certificate Authority Server A Root CA Server is a system used to issue, renew, and revoke digital certificates, generates certificate revocation lists (CRLs), and can publish certificates and CRLs to the Active Directory using LDAP Directory Service. It can be configured to accept requests from users, depending on the supplied information and can process requests either manually, that is with the aid a CA administrator or automatically, which is based entirely on customized policies and procedures within Active Directory. The Root CA has Active Directory installed for administrating the secure policies. In order to publish certificates to Active Directory, the Root CA server must be a member of the Certificate Publishers group. The Publishers group is a group policy that is configured within Active Directory. The Root CA is also configured with all PKI applications used Certificate Repository Server The Certificate Repository server also has Active Directory configured onto it with security policies. The Certificate Repository server is used to keep track of the pending certificate request, issued or revoked certificate, on the (CRL) within Active Directory. It is a library of certificates available where users, servers and processes can verify the subject. The main purpose of the Certificate Repository server is to help distributed the workload for the Root CA server. The Root CA server can only update the LDAP Directory Service on the Certificate Repository server within Active Directory. The LDAP provides access to the public CRL, user and CA certificate. Also, it provides a standard LDAP interface to native client for retrieving certificates, i.e. SSL client authentication

12 3.1.3 Certificate Template A certificate template is used to show certificates based on their intended use. When a user requests a certificate from a Windows 2000 enterprise certification authority (CA), the certificate requester will be able to select from a variety of certificate types that are based on certificate templates, depending on their access rights. A generated certificate from the college CA shall also use the X.509 standard for attributes. The generated certificates contain the following information with the X.509 attributes: User public key value User identifier information (such as the name and address, and or SSN#) Validity period (the length of time that the certificate is valid for) Issuer identifier information The digital signature of the issuer, which declare the validity of the binding between the subject public key and the subject identifier information. The Windows 2000 Certificate Services CA also uses the following PKCS standards PKCS#1 Describes how digital signatures are constructed using the RSA public key algorithm in conjunction with hash algorithms. PKCS#7. Describes how digital signatures and encryption are applied to any block of data. PKCS#10. Describes how to construct a certificate request message. PKCS#1 and PKCS#7 are used together to define the construction of signed messages. PKCS#10 is the standard that Windows 2000 Certificate Services uses to receive a certificate request. If the user wants to make a request, the Certificate Request Wizard shall be used. The Certificate Request Wizard is installed onto the certificate repository server. The Certificate Request Wizard is available to all users within the PKI. When requesting a certificate, the user can select from different certificate types depending on the user s rights. These certificate types shall be setup according to the Certificate Template on the Root CA. The enterprise CA model shall use the information available in Active Directory to help verify the requester's identity. All certificate requests sent to the enterprise CA will be fulfilled or denied based on the policy and security permission set for the certificate type requested. Enterprise CAs never set a certificate request to pending, they immediately either issue the certificate or deny the request. 3.2 Setup Trust for the CA The implementation of PKI for choosing a trust model in a certification authority is established when the college has a copy of the root certificate in the trusted root certification authority store. Once the model is installed on Window 2000, an enterprise root CA is automatically added to the Trusted Root Certification Authorities certificate Store within Active Directory for all users and computers in the domain. A valid trust certification path is now established between outside user and internal user for the enterprise CA models. 3.3 Certificate Repository The certificate repository stores all of the certificates used within the PKI issued by the Root CA server as well as all of the Certificate Revocation Lists. The certificate repository is a separate system that is connected physically to the Root CA system by means of network. The certificate repository system holds the CRL for verification and authentication

13 3.4 Renewal, Revocation, and Publishing a Certificate Revocation List The implementing of PKI s renewal strategy using Windows 2000 is to install configure Certificate Services. Certificate Services shall be used by the college to enforce a policy where the CA never issues a valid certificate beyond the expiration date of its own certificate. Different types of certificates that shall be used within the college PKI is Root CAs with a validity period that is specified during the configuration of the Certificate Services within the Active Directory, subordinate CAs which have a validity life span of about 2 years, and all other remaining CAs with a 1 year life span. The Certificate Authority program shall be used to renew, revoke, publish a CRL, using the diagnostic tools, and trouble-shooting. The importing and exporting features for certificate make connectivity to different outside section easier. The import and export of certificates can be done by the Microsoft Management Console (MMC). The Certificate snap-in within the MMC provides administrative tools for importing and exporting of certificates. This allows the college s PKI to import a certificate from an outside source (i.e. other Root CA) to distribute the new trust with the college s user. The following are the Certificate File formats that can be used with the college: PKCS#12 (Personal Information Exchange) Enables the transfer of the certificates and there corresponding private keys from computer-to-computer or removable media source. PKCS#7 -- (Cryptographic Message Syntax Standard) Enables the transfer of a certificate and all of its certificates in its certification path from computer-to-computer or removable media source. DER Encoded Binary X.509 Supports interoperability for CAs that are not on Windows based servers. DER certificate files Base64 Encoded X Supports interoperability for CAs that are not on Windows 2000-based servers. Base64 certificate files Now as Certificate Services process increase in number and frequency there is a physical impact on the Certificate Services requirement. This is reflected in Table 1. Each request results in a database size of 1 KB to 20 KB. Table 1, General Hardware Configuration Guidelines for Certificate Services, [MTnWi] Service Size Up to 10 KB Certificates 10 KB 100 KB Certificates 100 KB 1 MB Certificates Minimum Physical Memory (MB) Recommended Physical Memory (MB) Expected Database Size Up to 200 KB KB - 2 GB GB 20 GB 3.5 Active Directory Active Directory uses Lightweight Directory Access Protocol (LDAP) to provide a single place to find network resources. The PKI design shall use Active Directory as a centralized management interface for certificates. Active Directory can be setup to be the brain function behind PKI. Within Windows 2000 Server, administrators manage these accounts using the Active Directory Users and Computers. User accounts can be organized into containers called "organization units" that reflect the design of your Active Directory namespace. Authentication is not limited to users. Computers and services are also authenticated when they make network connections to other servers

14 Group Policy is also used within Active Directory to collect all computers, accounts objects and associate them to a security policy used within PKI to identify authentication trust relations. A folder in Active Directory, collecting appropriate computer account objects into the organizational unit, and then applying a Group Policy object to the organizational unit. The security policies specified in the Group Policy are then enforced automatically and consistently on all the computers represented by the computer accounts in the OU. Active Directory lets the Root CA Interoperability with other directory services. Because Active Directory is based on standard directory access protocol called LDAP, and the Name Service Provider Interface (NSPI), it can inter-operate with other directory services employing these protocols. LDAP is a directory access protocol that shall be used to query and retrieve information from Active Directory. Because it is an industry-standard directory service protocol, programs can be developed using LDAP to share Active Directory information with other directory services that also support LDAP. The communication between the Active directory and the Certificate Server is done through a LDAPv3 connection. LDAPv.3 provides the data exchange and a number of standard extensions to support. Strong Authentication Standard access control model Referrals Session confidentiality Digitally signed operations 3.6 Windows 2000 Applications Once the University s PKI is issued, published, and control certificates, the next step is to deploy applications that can use them. An application can make the use of public-key cryptography all but transparent to the user. The user should not need to know how cryptography works, where certificates are stored, or any of the other details they should simply indicate what they want done, and leave it to the applications and the PKI to make it happen. Applications can use digital certificates to deliver the benefits of public-key cryptography, also combine cryptographic functions like signing and encryption to make possible e-commerce, secure network access, or other desirable services. Table 2, Windows 2000 Enterprise Supported Applications, [MTnCh] Application Uses Secure Secure clients use certificates to ensure the integrity of e- mail and to encrypt messages for confidentiality. Secure Web Web servers can authenticate clients for Web communications communications (using client certificates) and provide confidential, encrypted, Web communications (using server certificates). Secure Web sites Internet Information Services (IIS) Web sites can map client certificates to authenticate users to control their rights and permissions for web site resources. Digital signatures Code-signing tools use certificates to digitally sign software files to Local network Smart Card authentication Remote access Smart Card authentication IPSec authentication Encrypting File System (EFS) recovery agent provide proof of file origin and to ensure the integrity of data. The Kerberos logon protocol can use certificates and the private key stored on smart cards to authenticate network users when they log on to the network. Servers that are running the Routing and Remote Access service can use certificates and the private key stored on smart cards to authenticate network users when they log on to the network. IPSec can use certificates to authenticate clients for IPSec communications. Recovery agent certificates enable recovery of EFS files encrypted by other users 14 14

15 3.6.1 Secure Exchange Key Management Service (KMS) shall be configured using Microsoft Exchange Server. Key Management Service software is included with installation of the Exchange Server in Windows Both configuration server utilities shall be installed and operated from the Root CA system. The Root CA Server can generate X.509v3 certificates which are used in standard S/MIME clients including Outlook Express, Outlook 98, and Outlook X.509v3 certificates are interoperable with the S/MIME standard and can be exchanged with internal users as well as users that are not using an Exchange/Outlook-based messaging system. The KMS needs to be started and running any time that a certificate is being issued, revoked, recovered, or renewed. The KMS is not used during normal client advanced security operations such as sending or receiving signed and sealed messages. The KMS database is used to store copies of all the keys and certificates that have been issued to the users on the University s PKI. Additional settings can be made for archive of the previous certificates that have been issued. When a mailbox is first configured for a user with Exchange Advanced Security, KMS generates a temporary enrollment key. The CA object's Enrollment tab sets policies for transmitting these enrollment keys and the types of certificates that will be generated, which is the X.509 v3. The information about this temporary enrollment key shall be delivered by hand to the users for first time setup of secure . Once the user accesses his/her mailbox on the Exchange Server, the session key is established to the client s program, i.e. Outlook Express. The root CA object's CTL tab allows the users of PKI to import digital certificates from outside organizations so that the user s can verify that certificates from that organization are properly authorized. This is useful if outside organizations want to send signed and sealed messages to the college using an S/MIME client. The other company would have to send the University a certificate from their own root CA server. Once this was done, users could exchange certificates that can be verified. The CRL is also responsible for removing certificates that are no longer required. When the KMS issues a certificate to a client, the certificate is valid for 12 months. Microsoft Exchange Server supports the following algorithms with S/MINE client: CAST-64, CAST-40, DES, 3DES, RC2-128, RC2-64, RC2-40. If the user is using OutLook Express application, then the certificates and private keys are stored in an EPF file. The encryption and decryption of S/MIME messages is handled by the S/MIME client, not the server Smart Cards Authentication Smart Cards can be used as a means of confidentiality, integrity, and authentication within the PKI network. Smart Cards provide users of the PKI with a tamper-resistant storage for protecting private keys and digital signatures. The Resource Manager is used to acknowledge all request for Smart-Card access. All requests are routed to the Smart Card reader through the Resource Manager. The Resource Manager is responsible for managing and controlling all application access to any smart card inserted into any reader attached to a Windows-based computer. Therefore, the Resource Manager provides a given application with a virtual direct connection to the requested smart card. The Resource Manager performs three basic tasks in managing access to multiple readers and cards. First, it identifies and tracks resources. Second, it controls the allocation of readers and resources across multiple applications. Finally, it supports transaction primitives for accessing services available on a specific card. It is important for the Resource Manger to manage all activity for the Smart Card, the reason is that the Smart Cards are single-threaded devices that have multiple commands at a single time. Transaction control allows multiple commands to be executed without interruption of the Smart Cards. A Smart Card reader shall be attached to a peripheral interface, such as RS-232, PS/2, PCMCIA, and Universal Serial Bus (USB). Secure application shall allow users to share information confidentially and to trust that the integrity of the information was maintained during transit. A user can select a public-key certificate issued by a trusted certificate authority to use for digitally signing and decrypting secure messages. Smart Cards can be used to add a level of integrity to secure e

16 mail applications because it stores the private key on the card, protected by a PIN. Possible upgrade solutions to using the Smart Cards with PKI applications is that the PIN could someday be replaced with a biometrics template of the user s fingerprint, thus enhancing the nonrepudiation aspects of digitally signed transactions Secure Web Communications and Sites Secure Socket Layer (SSL) shall be used with the secure web access that all users of the PKI have. SSL will operate between the Transport layer and the Session Layer of the OSI model. The application that shall use the SSL does not need to be modified as does the application that use IPSec. The SSL layer shall provide encryption for sanative information passed to across the web. The user s of the PKI shall be able to receive a certificate from a trusted third party such as VeriSign, or from Certificate Services. A Web server can only have one server certificate assigned to it. Digital Signature can also be used on the secure web by authenticating messages sent to an outside source. The digital signing of the message using the private key is possible with the user s Smart Card. One is called the SSL server authentication, which allows users to confirm a server s identity. The SSL server authentication shall be used to check that a server's certificate and public ID are valid and have been issued by a Root CA listed in the client's list of trusted Root CAs. The SSL client authentication allows a server to confirm a user's identity. Using the same techniques as those used for server authentication, SSL-enabled server software can check that a client's certificate and public ID are valid and have been issued by a certificate authority listed in the server's list of trusted CAs IPSec The implementation of PKI using IPSec is needed to provide a secure protocol for application traffic between the users and the Root CA. IPSec operates at the Network Layer of the OSI model. IPSec is available to any workstation/server that has an encrypted and digitally signed certificate stored in the computer account in the Active Directory. Using IPSEC within Windows 2000 can provide data privacy, integrity, authentication, and anti-replay protection for the network for end-to-end client/server, server/client, or even client/client using transparent mode. IPSec uses Active Directory to provide a secure environment for policy assignments and distribution. Active Directory delivers policy-based, directory-enabled networking using Group Policy within IPSec Windows 2000 domain members. Implementing Internet Key Exchange (IKE) with Internet Engineering Task Force (IETF) standard-based authentication method to establish trust between computers called Public/Private Key signature using certificates, compatible with several certificate systems, including Verisign, Entrust and Netscape. Within the Group Policy, IPSEC Policies can be established. The IPSEC Group Policy is configured with Server policy. You can use Group Policy to deliver the IPSec configuration, called an IPSec policy, to many clients and servers. This shall allow the PKI to communicate with non- IPSEC systems. If the requesting unsecured system does not comply with the IKE, then the secure system shall fall back to clear text. The IP Security Monitor shall be configured for monitor the policies. An IPSEC Filter List is used to match packets against filters when passing IP packets. The IPSEC transport and tunnel mode security filters shall be used. First, the IPSEC tunnel mode filters are applied to all packets. If there is no match, then the transport mode filters are applied. Transport filters apply to the host packets that have a source address from the system that is sending the packet, or the destination address of the system that receives the packet. IPSEC tunnels can only secure unicast IP traffic. Once the outbound filter is created, then a mirror process configuration shall automatically configure an inbound filter. The IPSEC Filter List is created, the next step is to assign action taken on those packets. The University s PKI shall be setup with a filter that can permit, block, and/or secure the packets that match the filters. The IPSEC policy specifies which Root CA to use within the PKI system. If the administrative team is creating a new rule for the Root CA, then the team can browse a list of certificate authority to use. IPSec authentication key value is stored inside the IPSec policy in a 16 16

17 readable format. IPSec policy is stored in the Active Directory and can be read any authenticated user, but modified only by the administrative team. Each rule used by IPSec defines a list of authentication methods. Each authentication method defines the requirements of how identities will be verified in communications to which the associated rule applies. Only one authentication method may be specified between a pair of computers, regardless of how many are configured. The two peers must have at least one common authentication method or communication will fail. If multiple rules exist that apply to the same pair of computers, configuration of the authentication methods list must be done first within those rules in order to enable the pair to use the same authentication method. For the PKI, this type of authentication within IPSec can be used with Internet access or remote access to corporate resources. The list of CAs is held within the IP Security Policies program under IP Rule editor. The IP Rule editor shall allow the college to build an ordered list of certification authorities that the Root CA can send in a request to the users during IKE negotiation. The users within the PKI must have a personal certificate issued by one of the Root CAs in the college s list in order for the authentication to be a success. The college can also add outside Root CAs that has entered into the PKI s trust relation Encryption File System Encryption File System (EFS) is based on public-key encryption, taking advantage of the CryptoAPI architecture in Windows. Each file is encrypted using a randomly generated key, called the file encryption key, which is independent of a user s public/private key pair. The Encrypting File System shall be used on the Root CA system for Windows Explorer will call EFS to encrypt the selected folders and provide the user a pop-up option to encrypt all existing files and any subfolders in the selected folders. EFS also provide users the ability to transfer encrypted files across systems. This is achieved through standard backup and restore mechanisms. The backup and restore methods shall also be used to recover the lost keys for file decryption. The recover key shall be sent to the user through to the user that needs to encrypt their file on the PKI network. The File Encryption Key (FEK) is a randomly generated key. The user s public key is used to encrypt FEK. The public key of the user is obtained from the user s X.509 certificate. The list of encrypted FEK is stored along with this encrypted file in a special EFS attribute called the Data Decryption Field (DDF). The private portion of the user s key pair is used during decryption and is stored safety off the Root CA system in the user s personal secure file or smart card. 3.7 PKI Application Program Interface The support of further application development is supported by the use of Application Program Interface (API) is to allow a programmer the ability to make their application PKI aware or utilize the security Windows 2000 provides. The PKI standard API for PKI integration is API (GSS-API), RFC The standard defines an open interface into a range of security services and was developed by IETF Microsoft also incorporates their APIs, CryptoAPI 1.0, CryptoAPI 2.0 and Security Services Provider Interface (SSPI). The APIs have the following roles [MTnAn], CryptoAPI 1.0 provides pre-written public and secret key cryptographic services. Applications can request encryption and decryption services without needing to know the intricacies of the algorithms and protocols used. CryptoAPI 2.0 provides certificate-handling services for certificate aware applications. It provides the ability for applications to request certificates, validate certificate chains, and get related information from the local or Active Directory certificate stores

18 SSPI allows developers to use Windows 2000 network security services. SSPI aware applications can map certificates to Windows accounts, establish SSL sessions, and open IPSec tunnels across the network. 3.8 Windows 2000 Supported Cryptographic Algorithms Windows 2000 includes support for the following cryptographic algorithms, public key encryption RSA and DSS, hash algorithms MD4, MD5, and SHA-1, and secret key algorithms RC2 and RC

19 Summary A security requirement is needed for a University security system. A University computer infrastructure is heterogeneous system with a diverse set of requirements and needs. The University security needs and requirements are just as diverse. The University must be able to support the availability as well as the security needs of its stakeholders. The Benefit of a PKI implementation is that the user can have a secure sign on. The University must develop a diverse set of requirements for the establishment of a PKI for its security foundation. The University will implement a hierarchical CA model with users attaching to their colleges or role certificate authority. The certificate authority will generate the certificate and store them in a repository server where they will be accessible from anywhere on the network. Windows 2000 Advanced Server operating system includes a native public-key infrastructure that is designed from the ground up, out-of-the box, to take full advantage of the Windows 2000 security architecture. Windows 2000 includes public key infrastructure that delivers the business benefits for the University using public-key cryptography. The user in the environment will have a single secure login that will authenticate them to the infrastructure. The user will then be able to use the applications they are accustomed to, i.e. and web, completely transparent to the security supporting their transaction

20 References [Hea01] Heatherly Douglas, Digital Certificates Are They Safe? May27, [Hir97] Hirsch, Frederick J. Introducing SSL and Certificates using SSLeay World Wide Web Journal, Summer [MTnAn] Microsoft TechNet, An Introduction to the Windows 2000 Public-Key Infrastructure [MTnCe] Microsoft TechNet Certification Authority [MTnCh] Microsoft TechNet, Chapter 12 Planning Your Public Key Infrastructure Windows 2000 Resource Kit. [MTnCr] Microsoft TechNet, Cryptography and PKI Basics Posted July 5, 2000, [MTnPr] Microsoft TechNet Prerequisites for Implementing PKI [MTnRu] Microsoft TechNet, Running a Windows 2000 PKI Project [MTnWi] Microsoft TechNet Windows 2000 Certificate Services [MTnW2] Microsoft TechNet Windows 2000 Server and Key Management Server Interoperability [Pfl97] Pfleeger, Charles. Security in Computing Prentice Hall PTR. Upper Saddle River NJ, [Pry01] Pryon, Roger. Interoperability in PKI July 25, [Sil01] Sills, Tim R. Implementing PKI in a Non-Heterogeneous Environment:: A Primer on Digital Certificates and Key Formats. August 27,

21 Acronyms API Application Programming Interface CA CRL DDF Certificate Authority Certificate Revocation List Data Decryption Field EFS Encrypting File System FTP FEK File Transfer Protocol File Encryption Key KMS Key Management Service LDAP Lightweight Directory Access Protocol IETF Internet Engineering Task Force IKE Internet Key Exchange IIS Internet Information Server IPSEC IP Security Protocol MMC NIC NSPI PKCS PKI SSL SSN SSPI Microsoft Management Console Network Interface Card Name Service Provider Interface Public Key Cryptography Standard Public Key Infrastructure Secure Socket Layer Social Security Number Security Services Provider Interface 21 21