Prepared By: P Lichen. P Xulu

Transcription

1 Local Certificate Authority Prepared By: P Lichen P Xulu 1

2 2

3 Abstract Today, security of information is most important in the Internet; for example, electronic commerce and electronic government affair. Digital certificate contains owner identity information and its owner s public key, so use digital certificate can ensure the certainty of identification, integrity of information and security of information transmission. The Certificate Authority (CA) is the organization which issue digital certificates and manage these digital certificates. If an organization build a Certificate Authority, the CA must be security and reliable. So we decide to design a system which used in Certificate Authority. Our system has the necessary functions to issue digital certificates to user and manage these digital certificates by organization. The system can satisfy CA s current demand. If the CA has the new demand, our project team could update the software in the future. 3

4 Introduction p4 1. Functional requirements p5-p8 2. Non-Functional requirements p9 3. Steps of request a digital certificate p10 4. Technology p11-p12 5. System requirements p13 6. Installation guide p13 7. User manual p13 8. Reference p14 4

5 Introduction: Local Certificate Authority is application software that used to issue and manages digital certificates. Any organization can use this software to build a Certificate Authority (CA). It has all ready functions; for example, create new digital certificate and signature digital certificate. Any administrator can use these functions to issue a signed digital certificate. In the system, each keystore has a keystore password and every private key has a private key password. And system can not keep the user s private key. System s certificate is store in a keystore alone. User can not get it, so it is security. So the system is more security and reliable. 5

6 1. Functional Requirements: Create: create a digital certificate for user. Information input: Common Name: user s name. Organization Unit: organizational unit name. Organization: organization name. Locality: locality name. State: state or Province name. Country: country name. Validity: the digital certificate s period of validity (days). 6

7 Signature: sign a user s digital certificate by system s digital certificate. Information input: Keystore Password: the keystore (LocalCALib) s password Certificate Password: the system s digital certificate s password Serial Number: the digital certificate s serial number Certificate Name: the name of digital certificate User Password: the user s private key s password Validity: the digital certificate s period of validity (years) 7

8 Effective Cert: list all of the signed and effective digital certificate and administer can manage the list (list, delete and move). Manage the effective certificates: List: list all of the effective certificates. Delete: delete a certificate. Administer need to input the certificates name and the password of keystore (SignedLib). Move: put an invalid digital certificate into the keystore (RevocationLib). Information input: Certificate Name: the name of digital certificate Keystore Password: the password of the keystore (SignedLib) 8

9 CRL: the invalid digital certificate list. Manage the CRL: List: list all of the invalid certificates. Delete: delete a certificate. Administer need to input the certificates name and the password of keystore (RevocationLib). Information input: Certificate Name: the name of digital certificate Keystore Password: the password of the keystore (RevocationLib) 9

10 2. Non-functional Requirements: 1. Constraints on the system: The Local Certificate Authority is designed for local certificate authority, so it is used in small organization and issue digital certificates to parts of people (the quantity of persons is very small.). Because the keystore has a limit number (the number is the certificates which store in it). 2. Reliability: Every keystore has a keystore password and every private key has a private key password. And system can not keep the user s private key. System s certificate is store in a keystore alone. User can not get it, so it is security. 3. Response time: The waiting time is very short. 4. Memory requirement: Run the system need not many memories. 5. Power consumption: The system has the simple programming and most of computer can run it and it is free for user. 6. Processing power requirement: The system is written by the Java, so the computer can support the Java 2 Platform Standard Edition

11 3. Steps of request a digital certificate: 1. User must provide the personal information to Certificate Authority. 2. User input the keystore password and private key password. 3. Create a digital certificate. 4. Use the CA s certificate to signature the user s digital certificate 5. Store the user s digital certificate and private key in user s keystore. 6. User gets the keystore (contains signed digital certificate and user s private key). Diagram: User User s information Input password Local Certificate Authority Create Certificate Get Keystore Certificate and private key Store Signed by system s certificate Signed Certificate 11

12 4. Technology: In the system, create a digital certificate use a important technology (ASN.1 DER). ASN.1: Abstract Syntax Notation number One (ASN.1) is a formal notation used for describing data transmitted by telecommunications protocols, regardless of language implementation and physical representation of these data, whatever the application, whether complex or very simple. ASN.1 DER: For signature calculation, the certificate is encoded using the ASN.1 distinguished encoding rules (DER). ASN.1 DER encoding is a tag, length, value encoding system for each element. Type Tag number (decimal) Tag number (hexadecimal) INTEGER 2 02 BIT STRING 3 03 OCTET STRING 4 04 NULL 5 05 OBJECT IDENTIFIER 6 06 SEQUENCE and SEQUENCE OF SET and SET OF PrintableString T61String IA5String UTCTime Example: the X.509 v1 certificate basic Fields Certificate ::= SEQUENCE { tbscertificate TBSCertificate, signaturealgorithm AlgorithmIdentifier, signaturevalue BIT STRING } TBSCertificate ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, serialnumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, validity Validity, subject Name, subjectpublickeyinfo SubjectPublicKeyInfo, } 12

13 Tools: In design the system, we use some tools to help us. BERViewer: the tool is very useful for design. Use the tool can see the certificate entry clearly. asn1view: a free tool to view asn1-decode file, or base64 decoded. UltraEdit-32: software which can use it write a file and view asn1-decode file, or base64 decoded. 13

14 5. System requirements: 1. Java 2 Platform Standard Edition 5.0 must be installed in user s system. 2. The platform is Microsoft Windows XP. 6. Installation guide: The system needs not to install in your computer system. Administer can click the LocalCertificateAuthority.bat to use the system. 7. User manual: 1. If user runs the system for the first time, you must be installing the LocalCA.cer at first. This file is the digital certificate of the system. 2. The system has two keystores (SignedLib and RevocationLib). All the signed digital certificates are store in the SignedLib. All the invalid digital certificates are store in the RevocationLib. Every keystore has a password and the password is written in the Password.txt. 3. Create: administer can use the function to create a digital certificate for user. But this digital certificate is not signed by system s digital certificate. 4. Signature: administer can use the function to sign user s digital certificate by system s digital certificate. 5. Effective Cert: administer can use the function to list all of the effective digital certificates. And manage the keystore by the provided functions. 6. CRL: administer can use the function to list all of the invalid digital certificates and manage the keystore 14

15 8. Reference: 中 国 信 息 安 全 组 织 : Sun Microsystems web page: Java How to Program Writer: Harvey M. Deitel and Paul J. Deitel ITU-T Recommendation X.690 (07/2002) RFC 2459 Internet X.509 Public Key Infrastructure January