Harbin Institute of Technology Cryptometry Experiment CA
As written before, today is 2021.12.19. The cryptography experiment has been accepted and meets all requirements. This article is an experiment report and is for reference only by juniors and juniors.
1. Background and significance
1.1 Significance of project development
With the rapid development of science and technology represented by information network technology, in the 21st century, we have entered an era of digital revolution with e-commerce as the core. The degree of global economic integration has been further strengthened, and the development of financial enterprises has The business environment has changed dramatically. What followed was a huge change in every aspect of our lives.
An important feature of e-commerce is the use of IT technology for information transmission and data processing. Therefore, e-commerce security should include two aspects: on the one hand, computer network security, and on the other hand, business transaction security. Business transaction security needs to focus on the security risks of traditional business applications in the Internet and be based on the computer network security foundation to ensure the smooth progress of the e-commerce process. This can ensure that e-commerce confidentiality, integrity, reliability and other goals are achieved as scheduled. From the perspective of computer network security, it is also closely related to e-commerce transaction security. The two influence each other and complement each other. It is necessary to build a relatively complete computer network security system and e-commerce transaction security system.
There are many problems of information leakage in e-commerce applications, mainly because the information of both trading parties is not effectively protected. For example, in the process of illegal attacks and theft of relevant information, one is to intercept and monitor the data in the transmission path through eavesdropping means to obtain valuable information, leading to information leakage; the other is to use the database server to discover Web programs and Network database vulnerabilities. Some network attackers use database attacks and eavesdropping to illegally obtain user information for business activities. Some attackers will use legitimate user information and identities to conduct transactions with others in order to obtain illegal rights and interests. This will not only destroy the reliability of trade, but also damage the credibility of traders. To put it simply, during an online shopping process, we will want to know: Is the shopping website trustworthy? Is the website where I store my money trustworthy? Is it a phishing website? In order to solve this trust problem, we introduced a third-party certification-CA certification center.
CA is the abbreviation of Certification Authority. CA center, also known as digital certificate certification center. As a trusted third party in electronic transactions, the CA center is responsible for issuing digital certificates to various entities in the e-commerce environment to prove the authenticity of each entity's identity, and is responsible for verifying and managing certificates in transactions; users of digital certificates have their own Public/private key pair. The certificate contains the identity information of the certificate subject, its public key data, the name of the issuing authority, etc. After the issuing authority verifies that the certificate subject is a legitimate registered entity, it digitally signs the above information to form a certificate. In the public key certificate system, if a public key user needs the public key of any other user registered with the CA, he can directly request the certificate from the user, and then use the CA's public key to decrypt and decrypt to obtain the certified public key; because The certificate already contains the CA's signature to achieve authentication. The attacker does not have the CA's signature key and it is difficult to forge a legitimate certificate, thereby achieving public key authentication. The digital certificate authentication center is a key link in the security of the entire online electronic transaction and the basis of trust in electronic transactions. He must be an authoritative, reliable and impartial third-party organization trusted by all legally registered users.
In a SET transaction, the CA not only issues certificates to cardholders and merchants, but also issues certificates to banks and gateways that receive payment. It is responsible for generating, distributing and managing the digital certificates required by all individuals participating in online transactions, and is therefore the core link in secure electronic transactions. It can also be said that without the existence of third-party certification, secure electronic transactions will not exist.
1.2 Domestic and foreign status quo and technology overview
Currently, digital certificates, as a relatively mature security product, have developed to a higher technical level, and will play an increasingly important role in our future online life. In layman's terms, a digital certificate is an individual's or organization's ID card on the Internet. A more professional definition of a digital certificate is that a digital certificate is a file containing public key owner information and a public key that is digitally signed by a certificate authority. The simplest certificates contain a public key, name, and digital signature of a certificate authority. Generally, the certificate also includes the validity time of the key, the name of the issuing authority (certificate authority center), the serial number of the certificate and other information. The format of the certificate follows relevant international standards. With digital certificates, we can have smooth access on the Internet. Digital certificates require very reliable security and confidentiality technology, that is to say, the four major elements of network security must be guaranteed, namely the confidentiality of information transmission, the integrity of data exchange, the non-repudiation of sent information, and the certainty of the identity of the trader.
CA technology is becoming more and more commonly used in the field of e-commerce. Most merchants and enterprises choose it because of its security. However, compared with developed countries in foreign countries, our country’s digital certificates are still In the initial stage, many companies are only trying in this field, and it is no wonder that there is a mixed phenomenon of good and bad people who perform their own duties. Therefore, it is very urgent to further improve our digital certificate field, and our country also needs this aspect. Talent. At present, my country's certification agencies are distributed in Tianjin, Beijing, Shanghai, Guangzhou, Hunan, Hubei, Shanxi and other places.
The X.509 standard is the format standard for public key certificates in cryptography. X.509 certificates have been used in many Internet protocols including TLS/SSL (the cornerstone of secure browsing on the WWW). At the same time, it also has many non-online application scenarios, such as electronic signature services. An X.509 certificate contains a public key and an identity (hostname, organization, or person) and is signed (or self-signed) by a Certificate Authority (CA). For a certificate that is signed by a trusted certificate issuing authority (or can be verified by other means), the owner of the certificate can use the certificate and the corresponding private key to create secure communications and digitally sign documents.
X.509 was first released together with X.500 on July 3, 1988. It assumes a strict hierarchy of certification authorities (CAs) that issue certificates. This is in sharp contrast to Web trust models such as PGP, where anyone can sign a certificate (not just a special CA) and thereby prove the validity of someone else's key certificate. The design of the X.509 V3 certificate is very flexible. In addition to supporting the bridge topology network, it can also support the point-to-point Mesh network, which is similar to the web trust mechanism like OpenPGP. However, this method was rarely used before 2004. .
In the X.509 system, the certificate applicant obtains a signed certificate by initiating a "Certificate Signing Request (CSR)". To do this, it needs to generate a key pair and then use the private key to sign the CSR (the private key itself must be kept properly and kept confidential). The CSR contains the applicant’s identity information and the applicant’s public address used to verify the CSR. key, as well as the distinguished name (DN) of the requested certificate. The CSR may also contain other identity proof information required by the CA. Then the CA issues a certificate for this distinguished name and binds a public key.
Organizations can distribute trusted root certificates to all members so that they can use the company's PKI system. Browsers such as Firefox, IE, Opera, Safari and Google Chrome are pre-installed with a set of CA root certificates, so you can directly use SSL certificates issued by these mainstream CAs. The developers of a browser directly influence the trust its users place in third parties. FireFox provides a list in csv/html format. X.509 also includes a standard for the implementation of Certificate Revocation Lists (CRLs), an often overlooked aspect of PKI systems. The IETF-approved method of checking certificate validity is the Online Certificate Status Protocol (OCSP), and Firefox 3 enables OCSP checking by default, as do later versions of Windows starting with Vista.
2. Requirements analysis
2.1 Overall needs
To complete the relevant required functions of a certification system, this CA certification system needs to be available for merchants, users, banks and other users to apply for certificate authentication. Each applicant must apply for a certificate after registering an identity account in the system. After filling in the correct information on the website application page, the system will review the application and issue a certificate in the format of cer, and allocate a private key. The certificate and private key distribution channel provides a download interface for the system, and the applicant can download it directly and join this website. In addition, the system provides related functions of usage methods. Merchants or banks can use their own certificates correctly according to relevant methods and combined with their own needs.
The CA system must encrypt all aspects involving user information to prevent information leakage. At the same time, it has management rights over the storage, revocation and recovery of certificates and private keys. Users have the right to view and modify their own information.
In addition, the system will record user operations and generate system logs to facilitate administrator review and audit.
2.2 Functional requirements
2.2.1 System functions
1) Registration: Username and password, open a CA account (the username cannot be the same, and the user may not be the real name)
2) Login: Enter the correct username and password. Log in to the CA system
3) Fill in/view/modify detailed information (CN, OU, O, L, email, etc...)
4) Certificate application: User Click on the certification application. In the application interface, enter the relevant complete information. After the system review is successful, the certificate will be distributed
5) Download the certificate and related files: Save the password generated by the website, enter the password to decrypt the private key, Ensure the security of private key transmission; there are three links to download the certificate, public key and private key respectively; click the safe clear button to ensure the security of private key transmission
6) How to use signature and verification: click the download link , download three files, and use the certificate correctly according to the usage method
7) Apply for revocation of the certificate: Revoke the certificate when the certificate information needs to be modified or the private key is leaked
8 )Private key recovery mechanism: When the user loses the private key locally, he or she can provide identity certificate to the system to view the private key again
9) Query certificate (validity check): View/download the CA of other users Certificate information, illegal users/this user’s latest certificate expiration reminder
10) Log function: record every step of the operation in the system, generate operation logs for administrator review and review
2.2.2 System security
Account security:
1) The user’s password information is not stored in clear text. It is transmitted and stored after hashing. The user password is stored securely; symmetrical is used during transmission. Key and public and private key encryption ensure transmission security
2) User-related information cannot be viewed by others. Only after I log in can I view it
3) Only after the uploaded personal information is reviewed by the administrator can the application for downloading the certificate be allowed. All accounts must ensure that the identity information is truly reliable
Transmission security:
1) Encryption-related operations are encrypted before transmission to ensure that the relevant information is not eavesdropped during the transmission. Leaked
2) The private key is also encrypted during transmission, and security will not be guaranteed during transmission. After the client decrypts it and is safely downloaded by the customer, the relevant files are safely deleted, and only the user's local files are retained.
Database security
1) As an important platform for information storage, the database needs encryption technology support and backup to prevent loss
Private key Storage Security
1) Use the principle of least privilege: strengthen authentication for system and network access; block all but necessary network ports; install all available security updates and run defense Virus scanner.
2) The key is stored in a secure encryption hardware device: It is best not to store the key on a general-purpose computer, which is vulnerable to attacks. Encrypted hardware devices are less vulnerable to attacks and are trusted by most important applications.
2.3 Performance requirements
1. Can be connected to e-commerce platforms and banks;
2. The system can work 24 hours a day;
3. The user authentication process requires Safe, reliable, and fast, the login time for ordinary users is less than 2 seconds;
3. Outline design
3.1 Development environment
Operating system: Windows 10
Database: Mysql
Language: java + html + jsp + css
Framework ：vue framework
3.2 Business data flow
User registration account => Registration certificate related details => User application for certificate => System audit => Distribute public and private key download interface and certificate download interface, and provide usage methods and related functions => Users can follow relevant methods and Use according to your own needs
3.3 Database design
First table: Account information table
Username is stored in plain text
Password is stored in hashed ciphertext
For example:
The second table: Certificate related information table, designed as follows
For example:
The third table: Save the public key< a i=3> For example:
3.4 Certificate structure and design
3.4.1 Certificate format
X.509, all certificates comply with the ITU-T X.509 international standard.
The structure of the X.509 certificate uses ASN1 (Abstract Syntax Notation One) to describe the data structure and is encoded using ASN.1 syntax. The X.509 standard defines what information should be included in the certificate and describes how this information is encoded (i.e. data format)
The most widely used standard at present is X jointly developed by the ITU and ISO .509 v3 version specification (RFC5280), which defines the following certificate information fields:
1) Version Number: The version number of the specification, currently version 3, with a value of 0x2;
2) Serial Number: A unique serial number maintained by the CA assigned to each certificate issued by it and used to track and revoke certificates. As long as you have the issuer information and serial number, you can uniquely identify a certificate, and the maximum length cannot exceed 20 bytes;
3) Signature Algorithm: the algorithm used in digital signatures, such as : sha256-with-RSA-Encryption, ccdsa-with-SHA2S6
4) Issuer: Identification information of the certificate-issuing unit, such as "C=CN, ST=Beijing, L= Beijing, O=org.example.com, CN=ca.org.example.com ";
5) Validity: The validity period of the certificate is very long, including the start and end time.
6) Subject: The identification information of the certificate owner (Distinguished Name), such as: " C=CN, ST=Beijing, L=Beijing, CN=person.org.example .com " ;
7) Subject Public Key Information: Information related to the protected public key:
1. Public key algorithm (Public Key Algorithm) The algorithm used by the public key
2. Subject public key: the content of the public key
3. Issuer’s unique number: represents the issuer’s unique information (Optional)
4. Subject unique number: unique information representing the entity certificate owner (optional)
5. Extensions
3.4.2 Certificate design
In order to have a deeper understanding of the signing process, add an extension to sign the user name (everyone in this system has only one user name, which is different from each other and is equivalent to a symbol of identity) and save it to The user key identifier is as follows:
The signature can be verified and if someone forges the certificate, it will be discovered.
When the user generates a certificate, he or she needs to submit relevant information to the CA (in actual situations, the user may need to bring relevant documents to the CA to provide proof of the applicant's authenticity. If the documents are missing or there are problems with the documents, Then refuse to issue the certificate, but in this system, the default users are all "good guys", and the "bad guys" will not apply for certificates) The CA automatically generates the file and places it locally on the server (the server thinks it is encrypted, and the bad guys will not Break into local files) and generate the folder structure as shown below
The contents of other folders are similar and will not be shown here.
4. Overview of experimental process
4.1 Registered design
Enter the URL to enter the login page (change the hosts file and put the IP into "Local Server", which can be skipped)
Click to register one and jump to the registration page
Information integrity: instant detection, the password and confirmation password must be consistent, and the three cannot be empty.
You can register successfully as required
Click to confirm and jump directly to the login page
4.2 Login design
After successfully logging in, enter the user page. There is a work panel on the left.
4.3 Improve basic information design
Fill in the information according to the actual situation and click Submit information. For demonstration purposes, fill in all the examples here.
4.4 Design of viewing information
4.4.1 View your own certificate information
4.4.2 Query other people’s certificate information
Enter the user name to be queried (in this system, the user name is similar to an ID card that symbolizes identity and is different for each user). If the query object exists and the certificate is valid, you can view the information, download the certificate and public key
4.5 Modify information design
The modification page is as follows. Fill in the information again to overwrite the previous information. For demonstration purposes, I modified everything to example.
Query again and find that it has changed
4.6 Apply for and download a certificate (secure transmission of private key)
The page is as follows
In the first step, in order to ensure the security of the transmission of the private key, a randomly generated key is needed to encrypt the private key file. Click the first button to get the key and save it.
The second step is to enter the obtained password into the password box.
In the third step, click the button to securely decrypt the key file. In the fourth step, you can download the file from the backend (the private key is transmitted securely)
Public key file ( It can also be obtained through a certificate. The relevant code on how to obtain the public key from the certificate is written in detail in the usage method.) Since it has been modified once, there is a record of the last public key (but the last public key has expired)< a i=2> Private key file (only the last valid private key): Certificate file: You can see that it is the example just generated The last step is to click Safe clear button to clear the front-end private key file to prevent the private key from being leaked. Note: The usage instructions are attached below, click to download
4.7 Revocation of certificate
After reading the instructions and selecting Read, you can submit the cancellation application, and the backend will automatically change the CRL.
5. Detailed design
We have seen a complete experimental process in the previous section. The following details the security details and implementation of the design.
5.1 Security during registration
When a user registers, the user name and password entered are sensitive information and should not be transmitted in plain text (security during transmission, that is, the adversary will not obtain the user name and password by directly capturing packets in the channel). Secondly, if only every Generate a session key at a time and use AES symmetric key encryption. The adversary can also crack the password within a limited time. Therefore, a symmetric key plus asymmetric key encryption scheme (hybrid encryption scheme) should be used. The symmetric key is used every time. Now generate, the asymmetric key selects the public and private keys in the CA certificate. Finally, the password stored in the database should not be in plain text, otherwise it will cause insecurity problems (database leakage or staff managing the database leaking sensitive information), so the password should be passed through one-way The function (hash function) is hashed and put into the database. The process is as follows.
The session key (symmetric key) is temporarily generated. Each key is randomly generated with equal probability, otherwise there will be security problems. Secondly, symmetric encryption uses AES encryption method, DES It is no longer safe.
The public and private keys of asymmetric encryption should be signed and certified by the CA. The sender should confirm that the certificate it obtained is indeed the other party’s certificate, and that the certificate is valid (not expired and the private key has not been leaked). Symmetric encryption scheme uses RSA encryption scheme. The signature scheme I used is SHA256withRSA.
5.2 Security when logging in
The encryption process during login is the same as above. After the data is transmitted to the backend, it is compared with the hash value stored in the database. If the data is the same, the login is successful, and if it is different, the login fails. Secondly, if the user has not been "audited" by the login page, the user will be directly By trying to bypass the login page by changing the URL, you will not be able to do unnecessary things (i.e. change information, etc.) and will only be allowed to query other people's credentials (guest mode?).
5.3 Private key security
Now we assume that example has submitted the information required to apply for a certificate. We need to apply for a certificate to obtain the certificate file and private key file. The certificate file and public key are both public and can be transmitted in plain text, but what about the private key file? What about secure delivery? Naturally, I thought of using the above method (5.1) to encrypt the file. However, as the CA system issues a certificate to the other party, the other party's certificate has not yet been passed to the other party, that is, the other party does not have its own private key and cannot encrypt with the other party's public key. Then Is it okay to encrypt (sign) with your own private key? Of course, this is not possible. As a CA, anyone can obtain the CA's public key, and anyone who obtains the CA's public key can decrypt the file, that is, anyone can decrypt the private key file.
So here, I can only settle for the next best thing and just use symmetric encryption to encrypt the file. The session key is the key that needs to be saved each time (step 4.5). The following shows the status of the file at each moment.
First, after filling in the necessary information for applying for a certificate, apply for the certificate and store the key file generated by the backend locally (in real life, the key is stored in a secure encryption hardware device. Encrypted hardware devices are less vulnerable to attacks and are trusted by most important applications. Secondly, set a complex protection password for the private key)
Secondly, click the first button and the private key will be The key file has been transferred from the backend and is stored in the front-end public\lab_certificate, but it is stored in ciphertext, as follows:
Third, enter the password and press the button. At this time, it is equivalent to passing the session key to the front end, and the front end decrypts the stored encrypted file. The user should quickly download the private key file, because at this time, the private key is actually unsafe.
Fourth, press the fourth button to completely clear the files decrypted by the front end, and the private key will no longer be exposed.
Here, I need to state that, first, I believe that the CA is completely trustworthy, that is, the CA will not be compromised by adversaries, and it is safe to store the key locally in the CA; second, the private key is in During the transmission process, the probability of session key exposure is negligible, which means that the private key is safe during the transmission process; thirdly, the user will immediately press the safe clear button after downloading the private key file, which means that the adversary will not be there. When the user downloads the private key, he downloads the private key file at the same time. If the above three conditions are met, the private key transmission process is guaranteed to be safe.
The following describes another method to achieve private key security, which is to generate public and private keys on the client. The specific method is as follows:
First, CA provides public and private key generation device.
Second, the customer generates the public and private keys locally and saves the private keys locally. This eliminates the need to transmit the private key file over the channel.
Third, the client directly transmits the public key to the server, and the server performs a series of signatures based on the public key and application information to generate a certificate.
Fourth, the server transmits the certificate to the client.
Complete the certificate application operation.
5.4 Using certificates
5.4.1 Implementation of signature
This system uses the SHA256withRSA method for signing. The specific code is placed in the SHA256withRSAUtil class, which contains two different signature/signature verification implementations, both of which have passed verification.
5.4.2 Certificate validity query
To query the validity of the certificate, there are two judgment criteria in this system: first, whether the certificate has expired; second, whether the certificate is issued by the CA system.
Expiration detection: The default validity period of each certificate is 10 days when it is generated, and it takes effect immediately from the time of generation. The validity period information is recorded in the database. When a user queries the certificate of another user, the backend will check the current time and expiration date to determine whether the certificate has expired. If it expires, the certificate will be deleted immediately and a prompt that the front-end certificate has expired will be returned; if it has not expired, the information will be returned normally.
Check whether the certificate is issued by the CA system: When generating the certificate, each certificate is signed by the CA system. Users can verify whether it is by downloading the usage method (SHA256withRSAUtil class) provided by this system. Signed by this system. The specific usage methods have been stated in the SHA256withRSAUtil class.
5.4.3 Asymmetric encryption using certificates
This system uses the RSA method for encryption. Two sets of specific codes are placed in the RsaUtil class and the CARSA class, and both have passed verification.
5.5 Others
5.5.1AES encryption
There are also two sets of symmetric encryption AES methods in the backend, which are placed in the AESUtile and AESFileUtil classes to encrypt and decrypt strings and files respectively. The front end also has a corresponding implementation in secret.js in Utils.
5.5.2 Log
The recorded logs are placed in the log folder
where each user’s information is clearly recorded
Please see the details for other details. code.