The normal operation of all business is inseparable from a safe operating environment. System security is directly related to business stability, reliability and availability. This chapter introduces some topics related to system security.

    Confidentiality: confidentiality

    Integrity:integrity

    Availability:availability

    Threat confidentiality attacks: eavesdropping, traffic analysis

    Threat Integrity Attacks: Change, Camouflage, Replay, Denial

    Threat Availability Attacks: Denial of Service (DoS)

    Technology: Encryption and Decryption               

            Encryption and decryption:

                Traditional Encryption Method: Replace Encryption Method, Replace Encryption Method

                Modern Encryption Method: Modern Block Encryption Method

    Services: Services that are below attack, that is, security services specially designed for the above security objectives

            Services:

                Authentication mechanism

                Access Control Mechanism

    Symmetric encryption: Encryption and decryption use the same secret key; however, encryption and decryption algorithms may differ

    The working process is as follows:

        The sender uses the secret key to encrypt the transmitted data into plaintext using the encrypted algorithm and sends it to the other party. After receiving the encrypted data, the receiver decrypts the data from the ciphertext to plaintext using the same secret key and the decryption algorithm.

    Common symmetric encryption algorithms:

            DES: Data Encryption Standard, 56-bit secret key

            3DES: Triple DES

            AES: Advanced Encryption Standard, supports 128-bit, 192-bit, 256-bit, 384-BIT secret keys

            Blowfish

            Twofish

            RC6

            CAST5

    Symmetric encryption:

        < 1 > Encryption and decryption use the same secret key

        <2> Separate the original data into fixed size blocks and encrypt them one by one.

    Defects of symmetric encryption:

        < 1 > Too many keys

        <2> Difficulty in Key Distribution

        < 3 > Data sources cannot be identified

    Public key: The public key is extracted from the private key and can be made public to everyone; pubkey

    Private key: Created by tools, the private key can only be used, but it can be saved by itself. It must be kept private.

    Characteristic: Data encrypted with public key can only be decrypted with the private key paired with it; conversely, data encrypted with private key can only be decrypted with the public key paired with it.

    Purpose:

        Digital signature: Mainly to let the recipient confirm the identity of the sender. The digital signature is to encrypt the data with the signature code obtained by using the single encryption (MD5, SHA) algorithm and its own private key.

        Secret key exchange: The sender encrypts a symmetrically encrypted secret key with the other party's public key and sends it to the other party for secret key exchange.

        Data Encryption: Data itself is seldom encrypted by public key, because the encryption efficiency of public key encryption is very low, so data itself is usually encrypted by symmetric secret key.

    The working mode of public key secret:

        Mode 1: Public key encryption, private key decryption

                B sends the data to A, B encrypts the data with A's public key, and then sends the encrypted data to A. At this time, the encrypted data can only be decrypted by A's private key. Therefore, even if a third party gets the encrypted data, it can not complete the decryption. Only A has its own private key, so it realizes the confidentiality of data.

        Mode 2: Private key encryption, public key decryption

                A encrypts a piece of data to B with its own private key. The encrypted data can only be decrypted by A's public key. Therefore, if a third party gets the encrypted data, it can be decrypted, because A's public key is public and anyone can get it, so it can be decrypted.

                But the function of this method is not to encrypt data, but to authenticate (digital signature). That is to say, A encrypts a piece of data with its own private key (data is not to send itself, but to encrypt data using the signature obtained by one-way encryption algorithm), and then sends it to B and B to decrypt the private key of A, which can be decrypted successfully. The explicit sender must be A, because only A's public key can unlock A's private key; once the data is unlocked, the signature to send the data is obtained. After the data is actually sent later, the signature can be used to verify the integrity of the data.

    Common algorithms for public key encryption:

        RSA: It can realize both digital signature and encryption and decryption.

        DSA: Sometimes also known as DSS, digital signature standard. Only digital signature can be realized, but encryption and decryption can not be realized.

    Characteristic:

        Fixed-length output: No matter how big the original data is, the feature codes are fixed-length.

        Avalanche effect: a small change in the original data will lead to tremendous changes in the signature

    Function: Mainly used to verify the integrity of data

    Common one-way encryption algorithms:

        MD5: Message Digest 5 Message Summary, Version 5. 128bit fixed length output

        SHA1: Secure Hash Algorithm 1, 160-bit fixed-length output

        SHA224,SHA256,SHA384,SHA512

    Common switching algorithms:

        Public Key Encryption: Encryption of symmetric keys with the public key of the other party, so that the other party can be solved with its own private key, thus obtaining the secret key of symmetric encryption.

        DH(Deffie-Hellman) algorithm:

                <1> A: a, P negotiate to generate open integer a, large prime p
                    B: a,p
                < 2 > A: Generate privacy data x, (x < p), calculate a^x%p and send it to B
                    B: Generate privacy data y, calculate a^y%p and send it to A
                <3> A: Calculates (a^y%p) ^ x = a^xy%p, and generates the key.
                    B: Calculates (a^x%p) ^ y = a^xy%p, and generates the key.

   A has a piece of data to be sent to B,A calculates the signature of the data with a one-way encryption algorithm, and A encrypts the signature with its own private key to generate digital signatures, so as to ensure the integrity of the data (by comparing signatures) and authentication (digital signatures), but it can not guarantee the confidentiality of the data, because the data itself has not been encrypted.

        Therefore, A will continue to generate a one-time symmetric encryption key based on the original data and digital signature, and then use symmetric encryption algorithm combined with the secret key to encrypt the original data and digital signature. Then, A encrypts the symmetric encryption key with B's public key, appends it to the data generated by the symmetric encryption algorithm before, and sends it to B.

        When B receives data, it decrypts the secret key attached to symmetric encryption with B's own private key, thus obtains the secret key of symmetric encryption (which completes the secret key exchange. In fact, both sides know that the secret key process of symmetric encryption is secret key exchange). Then it uses the secret key of symmetric encryption to further unlock the data and digital signature, and then uses the public key of A to unlock the digital signature. Name, get the signature of the data itself, then use the same single encryption algorithm to calculate the signature of the received data, and then compare the signature to verify the integrity of the data.

    There is still a serious loophole in the above communication process, that is, how can A know the public key of B, or how can B know the public key of A when A and B never communicate. Assuming that when A does not have B's public key, a request is sent to B requesting to know B's public key, but at this time, if a third party C obtains the request and pretends to be B, and then sends C's own public key to A, A considers C to be B. C will pretend to be A and communicate with B, thus obtaining the real public key of B. In the process of communication between A and B, C will be handed over, and the security of data can not be guaranteed. This is a man-in-the-middle attack.

    It consists of four parts:

        Visa Institutions: CA Institutions

        Registry: RA, equivalent to CA's dispatch office, is used to receive registration applications.

        Certificate revocation list: CRL

        Certificate Access Library: CB

    CA: Guarantee that both sides of the communication can reliably get the other party's public key (to avoid man-in-the-middle attack), and set up a trusted third party organization that both sides trust.

        A submits its its public key to CA. After special anti-counterfeiting treatment, CA sends the public key of the processed A to A. The public key of the processed A is called CA certificate. Later, if B requests the public key of A, A will send the CA certificate to B. When B gets the certificate, it will not immediately verify any certificate, but to verify whether the certificate is legitimate and whether it is issued by the CA agency trusted by B. Only after the certification is completed will it be recognized.

    CA certificates generally include: the name of the person who submitted the certificate, the public key of the person who submitted the certificate, the validity of the certificate, and then CA institutions will use their private key to encrypt the signatures of more than one whole piece of data, and then add the encrypted signatures (that is, digital signatures) to the data, the whole of which is the CA certificate.

    CA certificate has the data encrypted by CA's own private key to the signature of the certificate's content. To unlock the digital signature, the communicator needs to use the CA's own public key. But how to obtain the CA's own public key, if applied directly, then there will be the possibility of man-in-the-middle attack. Therefore, generally, CA will issue a CA certificate to itself. Then obtain CA's own certificate, generally can not be sent through the network, so in general, it is offline transactions.

    X.509, the standard for defining certificate structure and authentication protocol. In the standard of X.509, the structure that certificates need to have is defined:

        Version number: v1 or v2 or v3 version of X.509

        Serial Number: Serial Number of Certificates issued by CA Institutions

        Signature algorithm ID: The algorithm used for certificates

        Name of publisher: CA organization's own name

        Limit of validity of certificate

        Subject name: The name of the user requesting the CA certificate

        Principal public key:

        Distributor's Unique Identity: ID of CA Institution

        Unique identity of the subject: ID of the requester

        Extended information

        Publisher's signature: CA uses its private key to encrypt the signature of the above content, and generates a digital signature, which is appended to the content of the certificate as part of the certificate.

    SSL: Secure Socket Layer, released by Netscape in 1994, is divided into V1.0, V2.0 and V3.0. However, because its copyright belongs to Netscape Company, and there are protocol vulnerabilities in all versions, it is rarely used.

    TLS: Transport Layer Security, Transport Layer Security, is an SSL-like protocol issued by the International Association of Internet Engineers. It is divided into V1.0, V1.1, V1.2 and V1.3 versions. V1.2 versions are used more frequently.

    <1> Bottom Level: Implementation of Primitives for Basic Algorithms, such as AES, RSA, MD5

    < 2 > Up to the next level: the implementation of various algorithms, that is, the specific implementation of the algorithm

    < 3 > Up to the next level: Semi-finished products realized by combinatorial algorithm

    < 4 > Top level: all kinds of finished cryptographic protocol software assembled with various components;

    OpenSSL consists of three parts:

        libencrypt library: encryption and decryption library, dedicated to the implementation of encryption and decryption functions, mainly used by developers

        libssl libraries: libraries for implementing ssl secure communication mechanisms, mainly used by developers

        openssl multipurpose command line tool: openssl

    The client requests and verifies the certificate to the server (the certificate contains the public key information of the server);

    The symmetric secret key is generated by negotiation between the two parties.

    The process of encrypted communication between two sides using symmetric secret key

    After the session, disconnect

    This is the detailed process of negotiating encryption algorithm and generating session secret key before the formal start of the SSL session. (Take HTTPS protocol as an example)       

    < 1 > Stage 1: client-hello

        Client sends:

        Supported protocol versions, such as: tls1.2

        The client generates a random number to generate a symmetric secret key later

        Supported encryption algorithms, such as AES, RSA, SHA

        Supported Compression Algorithms

    < 2 > Stage 2: server-hello

        The server sends to the client:

        Confirm the protocol version of the encrypted communication used, such as tls1.2

        Generate a random number to generate a symmetric secret key later

        Encryption Algorithms Used for Confirmation

        Send Server Certificate to Client

        If necessary, it is possible to ask the client for the client's certificate (e.g. when the client requests an online banking page)

    < 3 > Phase 3: The client receives the server-hello response from the server

        Verify the server certificate, and if there is no problem, get the server's public key by decrypting the certificate.

        Contents of verification:

                Certificate issuing agency: Is it credible to verify the certificate issuing agency, that is, to verify the certificate signature (CA digital signature)?

                The integrity of certificates is also the decrypted signature in the digital signature of certificates.

                Certificate holder: Verify that the holder in the certificate is consistent with the page to be visited

                Certificate validity period

                Is the certificate revoked?

        Send the following information to the server:

                A random number used to generate symmetric secret keys

                Coding Change Notification: Indicates that subsequent information will be sent using a mutually agreed encryption method and secret key

                Client Handshake End Notification: Indicates that the client's handshake phase ends before formal communication

    < 4 > Phase 4: Server side

        After receiving the last random number sent by the client, the symmetric secret key is generated by using a total of three random numbers including the random number.

        Send the following information to the client:

                Coding Change Notification: Indicates that subsequent information will be sent using a mutually agreed encryption method and secret key

                Server-side handshake end notification: indicates that the server-side handshake phase has ended

    When A and B communicate, A is the client and B is the server.

    < 1 > A sends hello information to B, B sends hello information to A after receiving. At this time, to establish a pre-communication confirmation for both sides, it is necessary to negotiate the encryption algorithms used in the real communication between the two sides, including one-way encryption, symmetric encryption, public key encryption and secret key exchange methods.

    <2>A requests the certificate of B, and B sends its certificate (the public key after CA processing) to A.

            Generally, the client will not have certificates to provide to the server, because on the one hand, the use fee of certificates makes the client not to use them, on the other hand, when the client visits the server, it will not verify the identity of the client, such as visiting a website, the website will not require the client to have certificates before responding to the content to the client, while the client is to verify the server. Certificate, because in order to prevent access to the correctness of the site, prevent phishing sites, etc.

            But sometimes the server side will also verify the client's certificate, for example, when the client visits the online banking page, it will verify the certificate. When we go to the bank to open the online banking, there will usually be an encrypted dog or something like that. In fact, the user's own CA certificate is stored in it, but the issuing agency of the CA certificate is not a recognized CA institution on the market, but a bank. A self-established CA issuing agency is only valid for its own banks.

    After receiving B's certificate, verify B's certificate, if there is no problem with validation.

    After verifying that B's certificate is okay, A generates a random number as the secret key of symmetric encryption. A uses the previously negotiated secret key exchange algorithm (assuming public key encryption), then sends the secret key to B with B's public key encryption.

    <5>B receives the secret key of the message sent by A, decrypts the secret key of symmetric encryption by using its own private key, and then sends the data requested by A to A by using the secret key of symmetric encryption and the previously negotiated symmetric encryption algorithm, and transmits the normal data.

    <6> When the normal data transmission is completed, A (client) requests the communication to be disconnected, the server to be disconnected, and then the communication terminates.

    openssl command-line tools have many subcommands, which are mainly divided into three categories:

        Standard commands: enc, ca, req, genrsa...

        Message digest command (dgst subcommand related)

        Encryption command (enc subcommand related)

    <1> Complete symmetric encryption using openssl command-line tools:

        Tool: openssl enc subcommand

        Supported Algorithms: aes, des, 3des, etc.

        Use of enc command:

            openssl enc -CIPHERNAME -e|d -in /PATH/TO/FILE -out /PATH/TO/FILE 

            Option Explanation:

                - CIPHERNAME: The name of the encrypted algorithm, which can be viewed through openssl - help

                - e|d:- e denotes encryption and - D denotes decryption

                - Files to be encrypted in/PATH/TO/FILE

                - Out/PATH/TO/FILE Encrypted Files

                - What is the secret key of pass STRING for symmetric encryption

                - a|-base64 means encoding in base64 text format. If not specified, it may be encoding in binary format.

            For example, / testdir/file1 is symmetrically encrypted:

                When OpenSSL enc-des3-e-a-salt-in/testdir/file1-out/testdir/jmfile1 is inputted and returned to the train, the key of symmetric encryption will be required to be inputted. Encryption can be completed when the input is completed.

                        - Des3 denotes encryption algorithm using des3, -a denotes encoding in base64 text format, and-salt denotes adding point impurities.

            Decrypt the encrypted file above:

                Openssl enc-des3-d-a-salt-in/testdir/jmfile1-out/testdir/file2 enters and returns to the train. The key of symmetric encryption is required to be input and decryption can be completed when the input is completed.

        Tools: passwd, openssl passwd

        For example:

        Openssl passwd-1-salt 12345 and then return, will prompt you to enter the password, after the completion of the input, you can generate the encrypted password.

            - 1 denotes encryption using md5

            - SalSTRING represents the content of impurities added to the password generation

            - The impurities added after salt can be generated by random numbers, and the generated random numbers can be generated by subcommands of openssl.

                    openssl passwd -1 -salt `openssl rand -hex 4` 

        Tool: openssl rand

        Usage: OpenSSL Rand [-out FILE] [-base 64] [-hex] NUM

            - OutFILE means to save the generated random number in a file

            - Base64 denotes the use of base64 encoding. The generated random number may be followed by= and the real random number is removed after=.

            - hex denotes the use of hexadecimal digital encoding

            NUM represents the length of the generated random string

        Such as:

            openssl rand -base64 10

            Represents a random number of 10 bytes, which is output in base64 encoding format

            openssl rand -hex 10

            Output Random Number of 16-byte Length of 10 Bytes, equivalent to output 20 Characters

        Random Number Generator on Linux:

            / dev/random: Returns only random numbers from the entropy pool. When the random numbers are exhausted, the application of subsequent request random numbers will be blocked.

            / dev/urandom: Returns random numbers from the entropy pool. When the random numbers are exhausted, the software generates pseudo-random numbers without blocking them. Pseudo-random numbers are not safe

            Sources of random numbers in the entropy pool:

                I/O Interruption Time Interval of Hard Disk

                Keyboard I/O interrupt interval

        Encryption and decryption:

                Supported Algorithms: RSA, ELGamal

                Tool: openssl rsautl

        Digital signature:

                Supported Algorithms: RSA, DSA, ELGamal

                Tool: openssl rsautl

        Secret Key Exchange

                Supported Algorithms: DH, RSA

        Private key generation: (public keys do not generally need to be generated, but are automatically extracted from private keys generated)

            openssl genrsa 512|768|1024|2048... Represents generating a length of 512, 768... Bit Private Key

            OpenSSL genrsa 1024 >/PATH/TO/FILE means that a 1024-bit private key is generated and saved to a file

            OpenSSL genrsa 1024-out/PATH/TO/FILE also indicates that a 1024-bit private key is generated and saved to a file.

        The generated private key file can not be accessed by others, so the permission of the private key file should be changed to 600. In order to simplify the steps, the permission of the private key file can be defined directly when the private key is generated, such as:

            (umask 077;openssl genrsa 1024 -out /PATH/TO/FILE)

            In parentheses, it is equivalent to running in a sub-shell, so the umash setting of the sub-shell at this time only works for the sub-shell.

        Extracting public keys from private keys: Generally no manual extraction is required

            OpenSSL rsa-in/PATH/TO/private key file-pubout

            Represents the extraction of a public key from a private key file