WSE 3.0 Security

Symmetric cryptography and Asymmetric cryptography (asypolicric Algorithm)
A symmetric password has only one key, which is used for encryption and decryption. An asymmetric password has two keys. One key can be used as the public key to notify others. The other key can only be known to others as the private key. Data Encrypted with the public key can only be decrypted with the private key, data Encrypted with private keys can only be decrypted with public keys.
Using a symmetric password, both parties need to know the key. To verify the identity, the sender may need to pass the key to the receiver. This method may cause some potential security problems. In an asymmetric password, A uses its own private key to encrypt the data and then sends it out. If other people can use the public key of A to decrypt the data, then we can know that this data must come from A-Non-repudiation, which is generally in the user's digital signature. If other people need to send data to A, they can use the public key of A to encrypt the data, in this way, only A can decrypt the encrypted data-confidentiality, which is used to ensure the confidentiality of communication. Both parties that use asymmetric passwords each have their own public and private keys. When sending data to the other party, the other party uses the public key for encryption and the other party uses the private key for decryption.
Symmetric cryptography algorithms are simple, efficient, and have short keys. However, they are difficult to decrypt and can be quickly decrypted. Asymmetric passwords are generally weaker. In order to prevent deciphering, the length of keys used will be longer, such as 128 bits and 512 bits. encryption and decryption takes a long time. To improve the performance of secure applications during communication, the sender uses a symmetric key to encrypt the message, and then the receiver's public key to encrypt the symmetric key, send them together to the receiver. The receiver decrypts the symmetric key with its own private key, and then decrypts the message data with the symmetric key. In this way, when the transmitted information is large, the improvement is obvious. You can see this operation in the X.509 section.

Digital Signature
Digital signature is another application of the public key system. A needs to send A packet to B. First, A uses A specific Hash algorithm to obtain A Hash value of A certain length (such as 128 bits) for the packet to be sent, this Hash value is called a Digital Digest ). The Hash algorithm tries to ensure that the digest generated by different packets is different. That is, if the sent packet is modified by an attacker halfway, the new digest is different from the original digest. Then, A uses its own private key to encrypt the abstract. The encrypted value is called Digital fingerprint and Digital Signature ), A sends the digital signature along with the message to be sent to B. After receiving the content, B obtains the digital signature and message, decrypts the signature using the public key of A, and obtains the original digital abstract, B then uses the same Hash algorithm to obtain the digest value of the message and compare whether the two digest values are consistent. If the verification is successful, B can determine two things: 1. The data is indeed sent by A; 2. The data has not been modified during the sending process.

Simple Description of common theft and attack scenarios
The most common method of application system authentication is user name and password authentication. If authentication information is sent to the server in plaintext mode, the hacker can easily intercept the user name and password on the route.
To prevent attackers from intercepting the plaintext password, the simplest method is to encrypt the password and send it. However, although the attacker has no idea about the original password, the encrypted password string can still be verified by the server, this is also a form of Replay Attack. The solution is to encrypt the client with a random sequence and password each time, so that the encrypted result is different. The client sends the random sequence and the encrypted value to the server at the same time, the server uses the same method to encrypt the data with the original password and random sequence, and compares the encrypted data with the encrypted data sent from the client.
This solution has not solved the problem, because attackers can still intercept the encryption results and random sequences in messages for server verification. Another processing method must be added: Expiration Policy. In addition to the random sequence, the client adds a creation time and encrypts Password, Nonce, and CreatedTime together, for example, if the encryption value is Base64 (SHA-1 (Password + CreatedTime + Password), the client sends the encryption value, random sequence Nonce, and creation time CreatedTime together to the server. The verification mechanism on the server has changed. First, the Nonce of each request of the client uses a unique identifier and does not repeat. The server maintains a processed Nonce cache. Each time a message is received, it first checks whether the Nonce exists in the cache. If yes, the message has been processed, never request the service this time. If it does not exist, add the Nonce to the cache and process the request. To avoid the increasing number of cached Nonce values, use a CreatedTime and determine an expiration time, for example, 5 minutes later, the server only needs to save the Nonce value that has not expired within 5 minutes. In replay attacks, the server rejects authentication information from expired messages. If you pass the preceding two checks, the server uses the same algorithm Base64 (SHA-1 (Password + CreatedTime + Password) to verify the authentication information. By doing so, we can ensure that each encryption result of the authentication information is different and can only be used once.

X.509
You can query x.509from http://www.rfc.net.
It is unclear how to use X.509 in WSE 3.0, but the steps for the approximate digital signature are as follows:
1. A. Prepare the information to be transmitted (plaintext ).
2. A performs A Hash operation on the number information to obtain A Digital Digest ).
3. A uses its own private key to encrypt the Digital abstract, obtain the Digital Signature, and attach it to the information.
4. A randomly generates an encryption key (DES key) and uses this key to encrypt the information to be sent to form A ciphertext.
5. A encrypts the randomly generated encryption key with the public key of B, and transmits the encrypted DES key together with the ciphertext to B.
6. B receives the ciphertext sent by A and the encrypted DES key, decrypts the encrypted DES key with its own private key, and obtains the DES key.
7. B. Use the DES key to decrypt the received ciphertext and obtain the plaintext information.
8. B uses the public key of A to decrypt the digital signature of.
9. B uses the same Hash algorithm to Hash the received plaintext to obtain a new number digest.
10. B. Verify that the decrypted number digest is consistent with the self-computed number digest.
Symmetric cryptography uses the same key to encrypt and decrypt messages. Therefore, both the client and server have a password storage problem. During verification, the password information is directly or indirectly transmitted, this mechanism brings some insecure factors. Due to such factors, asymmetric cryptography, especially X.509, is widely used in Internet e-commerce.

Kerberos
The Kerberos procedure in RFC is as follows:

1. Kerberos authentication service request (KRB_AS_REQ)
The user enters the user name and password to log on to the workstation machine. The workstation sends Authentication information to the AS (Authentication Service) of the KDC (Key Distribution Center. The authentication information only contains the user account and does not contain the user password.
2. Kerberos authentication service response (KRB_AS_REP)
AS creates Session Key (Session password) SK1 for communication between workstation and TGS (Ticket Granting Service Ticket Authorization Service, use the password of TGS to encrypt the client information, TGS service information, SK1, timestamp, and validity period to generate a TGT (Ticket Granting Ticket authorization Ticket ). At the same time, KDC queries the user password in the user account database, and encrypts and packages the TGS service information and SK1 with the user password. Finally, AS sends the encrypted package and TGT to the workstation.
After receiving the returned information, the workstation decrypts the encrypted packet using the user password entered during user logon. If the decryption succeeds, it indicates that it has passed the KDC identity authentication, and get the TGS service information and SK1, and have the TGT.
First, the user password is only known to the user and KDC. When the workstation authenticates KDC, it does not send the user password to the AS of KDC, instead, you can prove yourself by letting the workstation decrypt it on its own. If the workstation cannot be decrypted, it will not be able to communicate with TGS, and thus cannot use other application services and resources.
Second, AS issues a TGT to the workstation, and the workstation will use the TGT to request other application services from the TGS, without the need to verify the user name and user password for SSO.
Third, TGS has its own password, which is only known to TGS and AS. Therefore, even though the workstation obtains the TGT, the password is encrypted using the TGS password, others, including Workstation, cannot decrypt or tamper with the content in TGT. It only needs to send this TGT when applying for other application services from TGS.
Fourth, AS generates a Session Key SK1 for the communication between the workstation and the TGS. This SK1 is shared between the workstation and the TGS so that when the TGS and the workstation communicate with each other, TGS can authenticate the client of the workstation. The preceding figure shows how the workstation gets SK1, while the AS does not directly tell the TGS SK1. In the following steps, you can see how the TGS gets SK1.
3. Kerberos ticket-granting service request (KRB_TGS_REQ)
When a user on the workstation requests other application system services, such as the mail Service, the mail client first queries whether the workstation has the Service Ticket (Service Ticket) of the mail Service ), if not, apply for the Service Ticket from TGS.
The process for applying for Service Ticket is as follows. The workstation uses SK1 encryption to generate a authenticator and send it to TGS together with TGT.
After receiving the wks request, TGS decrypts the TGT using the TGS password to obtain the content in the TGT. Check whether the token has expired Based on the timestamp and validity period. If the token has not expired, use the SK1 decryption validator to compare the client information in the validator with that in TGT. If they are consistent, the request passes TGS authentication.
4. Kerberos ticket-granting service response (KRB_TGS_REP)
From the decryption content of the validators, TGS knows that the workstation is applying for the mail Service's Service Ticket. Similarly, TGS creates a Session Key SK2 for communications between the workstation and the mail service, and encrypts client information, mail service information, SK2, timestamp, validity period, and other information using the mail service password, generate the mail Service Ticket. TGS uses SK1 to encrypt SK2 and sends the encrypted package along with Service Ticket to the workstation.
First, we can see from Steps 3 and 4 above how the TGS obtains the session password SK1 established between the AS and the workstation, and uses this SK1 to verify the workstation request. In the same way, TGS creates a session password SK2 for communications between the workstation and the mail service.
Second, the mail service has its own password, only known to the TGS and mail service itself. The email Service Ticket is encrypted using the email Service password. Others, including workstations, cannot be decrypted. Only the email Service can be decrypted by itself.
5. Kerberos application server request (KRB_AP_REQ)
Next, the workstation obtains the Response Message of TGS, which obtains the mail Service Ticket and an encrypted package. Workstation uses SK1 to unbind the encrypted package and obtain the session password SK2 for communication between it and the email server.
The workstation then encrypts the client information using SK2, generates a validators, and sends the validators and the mail Service Ticket together to the mail server to request the mail Service.
After receiving a request from the workstation, the Mail Service uses the password to decrypt the Service Ticket and obtain the content. First, check the mail Service information in the Service Ticket to check whether the Service is being requested from the user. Then, check whether the expiration date is based on the timestamp and validity period. If it does not expire, use the SK2 decryption validator to compare the client information in the validator with the client information in Service Ticket. If all the above verification passes, the request passes the authentication of the email server.
6. Kerberos application server response (optional) (KRB_AP_REP)
In the RFC standard, this step is optional. After the application service processes the request, if you need to send the information to the workstation, send the information back to the workstation.

It should be noted that in Kerberos V5, in order to prevent the Replay Attack (Replay Attack), the processing of the validator is not detailed. First, use some processing to make the validators different each time. The validators themselves have a validity period of about 5 minutes. A validators cache will be created on the server to ensure that one validators can only be used once within the validity period.
In addition, the AS and TGS of KDC in RFC standards can be combined or separated on different servers.
The above process shows that Kerberos uses symmetric passwords, while the symmetric Password algorithm is efficient and the key is short but difficult to decrypt. If you take other measures, such as Strong Password (Strong Password) password validity period control, etc., without considering other factors such as the integrated application, this mechanism itself is very strict, the confidentiality is relatively high. For some Attack and Defense scenarios of the Kerberos mechanism, refer to the design of an authentication system. The Chinese version is provided here, and the translation in many places is not accurate enough. Microsoft implements Kerberos based on the domain environment. For details, refer to the official Microsoft website, for example, Kerberos Authentication Explained; How the Kerberos Version 5 Authentication Protocol Works.
Currently, Kerberos can only be used in one Intranet, such as Microsoft's domain environment, because of the Kerberos mechanism and integrated applications.