How can we distinguish and use encryption and authentication technologies correctly? (1)

How can we distinguish and use encryption and authentication technologies correctly? (1)

Among cryptography experts, "encryption is not authentication" is a simple consensus. However, many developers who do not understand cryptography do not know the meaning of this sentence. If this knowledge is more widely known and deeply understood, it will avoid many design errors.

This concept is not difficult, but on the surface, there are more details and mysteries to be found. This article describes the obfuscation and misuse of encryption and authentication by developers and provides excellent solutions.

0x01 what are the differences between encryption and authentication?

Encryption is the process of rendering information, making it difficult to read without a correct key. In simple symmetric encryption, the same key is used for encryption and decryption. In asymmetric encryption, you can use the user's public key to encrypt information so that only the owner of the corresponding private key can read it.

Authentication is used to present information and prevent tampering (usually within a very low probability, less than 1 divided by the number of particles in the known universe ), it also proves that it originated from the process of the expected sender.

Note: When authenticity is mentioned in this Article, it refers to information authenticity rather than identity authenticity. This is a PKI and key management issue, which we may detail in future blogs.

For CIA triad: encryption provides confidentiality and authentication provides integrity.

Encryption does not provide integrity; tampered information (usually) can be decrypted, but the result is usually garbage. Separate encryption does not prevent malicious third parties from sending encrypted information.

Authentication does not provide confidentiality; it can protect plain text information against tampering.

In programmers, the common mistake is to confuse these two concepts. You can easily find such a library or framework: encrypt cookie data, and trust and use it unconditionally after only decrypting it.

0x02 Encryption

We have previously defined encryption and described in detail that it provides confidentiality, but does not provide integrity and authenticity. You can tamper with the encrypted information and send the generated garbage to the recipient. In addition, you can even use this garbage generation mechanism to bypass security control.

Consider the following code when encrypting cookies:

 
 

  
  
function setUnsafeCookie($name, $cookieData, $key)  
  
  
{  
  
  
    $iv = mcrypt_create_iv(16, MCRYPT_DEV_URANDOM);  
  
  
    return setcookie(  
  
  
        $name,   
  
  
        base64_encode(  
  
  
            $iv.  
  
  
            mcrypt_encrypt(  
  
  
                MCRYPT_RIJNDAEL_128,  
  
  
                $key,  
  
  
                json_encode($cookieData),  
  
  
                MCRYPT_MODE_CBC,  
  
  
                $iv  
  
  
            )  
  
  
        )  
  
  
    );  
  
  
}  
  
  
function getUnsafeCookie($name, $key)  
  
  
{  
  
  
    if (!isset($_COOKIE[$name])) {  
  
  
        return null;  
  
  
    }  
  
  
    $decoded = base64_decode($_COOKIE[$name]);  
  
  
    $iv = mb_substr($decoded, 0, 16, '8bit');  
  
  
    $ciphertext = mb_substr($decoded, 16, null, '8bit');  
  
  
   
  
  
    $decrypted = rtrim(  
  
  
        mcrypt_decrypt(  
  
  
            MCRYPT_RIJNDAEL_128,  
  
  
            $key,  
  
  
            $ciphertext,  
  
  
            MCRYPT_MODE_CBC,  
  
  
            $iv  
  
  
        ),  
  
  
        "\0"  
  
  
    );  
  
  
   
  
  
    return json_decode($decrypted, true);  
  
  
} 
 
 

The above Code provides AES encryption in the password segment link module. If you pass in a 32-byte string as $ key, you can even claim that, provide 256-bit AES encryption for your cookie, and people may be misled to believe it is safe.

0x03 how to attack unauthenticated Encryption

For example, after logging on to this application, you will find that you receive a session cookie, which looks like

Bytes + sQ =

Let's change the first block (initialization vector) of a byte and send our new cookie repeatedly until there are some changes. A total of 4096 HTTP requests should be taken to try all possible single-byte changes in the variable IV. In the above example, after 2405 requests, we get a string that looks like this:

Bytes + sQ =

In contrast, there is only one character in the base64 encoded cookie (kHv9PAlStPZaZ J vs kHv9PAlStPZaZ ):

-Bytes + sQ =

+ Keys + sQ =

The raw data we store in this cookie is an array that looks like this:

 
 

  
  
array(2) {  
  
  
  ["admin"]=> 
  
  
  int(0)  
  
  
  ["user"]=> 
  
  
  "aaaaaaaaaaaaa"  
  
  
 } 
 
 

However, after only one byte of the initialization vector is changed, we can rewrite our reading information:

 
 

  
  
array(2) {  
  
  
  ["admin"]=> 
  
  
  int(1)  
  
  
  ["user"]=> 
  
  
  "aaaaaaaaaaaaa"  
  
  
} 
 
 

Depending on the setting method of the underlying application, you may be able to flip one to become an administrator. Even if your cookie is encrypted. If you want to reproduce our results, our encryption key is in hexadecimal format: 000102030405060708090a0b0c0d0e0f