Advertisement

Verification of LINE Encryption Version 1.0 Using ProVerif

  • Cheng Shi
  • Kazuki Yoneyama
Conference paper
Part of the Lecture Notes in Computer Science book series (LNCS, volume 11049)

Abstract

LINE is currently the most popular messaging service in Japan. Communications using LINE are protected by the original encryption scheme, called LINE Encryption, and specifications of the client-to-server transport encryption protocol and the client-to-client message end-to-end encryption protocol are published by the Technical Whitepaper. Though a spoofing attack (i.e., a malicious client makes another client misunderstand the identity of the peer) and a reply attack (i.e., a message in a session is sent again in another session by a man-in-the-middle adversary, and the receiver accepts these messages) to the end-to-end protocol have been shown, no formal security analysis of these protocols is known.

In this paper, we show a formal verification result of secrecy of application data and authenticity for protocols of LINE Encryption (Version 1.0) by using the automated security verification tool ProVerif. Especially, since it is claimed that the transport protocol satisfies forward secrecy (i.e., even if the static private key is leaked, security of application data is guaranteed), we verify forward secrecy for client’s data and for server’s data of the transport protocol, and we find an attack to break secrecy of client’s application data. Moreover, we find the spoofing attack and the reply attack, which are reported in previous papers.

1 Introduction

1.1 Background

With the development of network communications technology, more and more people use messaging services to communicate. LINE is currently the most popular messaging service in Japan. Thus, if there is security vulnerability in LINE, widespread incidents may be caused due to its popularity. Hence, it is required that the security of LINE is rigorously analyzed.

In order to ensure the security of LINE, communications in LINE are protected by a dedicated encrypted communication scheme, called LINE Encryption, and specifications of the client-to-server transport encryption protocol (TEP) and the client-to-client message end-to-end encryption protocol (E2EEP) are published by the Technical Whitepaper [1]. In [1], some informal security analyses of the TEP and the E2EEP are shown, and it is claimed that the TEP satisfies forward secrecy such that “In the event that a private key is leaked, messages that were encrypted before the leak are protected if the communication supports forward secrecy” [2]. Since there are two kinds of messages (client’s application data encrypted by temporary key \(\mathbf{{key}}_\mathrm{temp}\) and server’s application data encrypted by forward secure key \(\mathbf{{key}}_\mathrm{FS}\)) in TEP, we need to consider two kinds of forward secrecy (i.e., forward secrecy for client’s data and forward secrecy for server’s data).

On the other hand, Espinoza et al. [3] showed a reply attack against the E2EEP. A man-in-the-middle (MTM) adversary can send an encrypted message in an old session as the message in the new session without changing the content of the message. Though the adversary cannot know the content of the message, the receiver client accepts these two messages as valid. Isobe and Minematsu [4] showed a spoofing attack against the E2EEP. A malicious client \(C_3\) intercepts the E2EEP between clients \(C_1\) and \(C_2\), and impersonates \(C_1\) to \(C_2\). Hence, since another unknown attack may exist, security of LINE Encryption is still unclear.

On the other hand, since it is difficult to analyze all attacks by hands, such as the replay attack or the spoofing attack, automated security verification methods by using formal methods have been studied to formally verify the security of cryptographic protocols.

1.2 Contribution

In this paper, we give the first formal verification result of the security of LINE Encryption (Version 1.0) by using the automated security verification tool ProVerif [5]. Specifically, for TEP, we verify forward secrecy of both client’s application data and server’s application data, and server authenticity. For E2EEP, we verify secrecy of application data and authenticity. For verifications of forward secrecy, we use reachability to application data for the adversary. For verifications of authenticity, we use correspondence assertions of some events. We obtain the following verification results:  
For TEP:

We find an attack to break forward secrecy for client’s data, but forward secrecy for server’s data and server authenticity are not broken.

For E2EEP:

We find the spoofing attack and the replay attack, but secrecy of application data is not broken.

  Thus, our verification result captures all known attacks to LINE Encryption, and points out the attack to forward secrecy for client’s data, which is not formally reported. Therefore, our result clarifies that the automated verification tool is useful to verify the security of messaging protocols.

2 Preliminaries

2.1 Client-to-Server Transport Encryption Protocol (TEP)

The client and server exchange the following messages in order to establish the transport key used to protect application data.

Static Keys. In order to guarantee that clients only connect to legitimate the LINE servers, TEP uses static ECC and ECDSA key pairs. The LINE servers securely stores the private part of each pair, while the corresponding public keys are embedded in LINE client applications.

  • ECDH key pair for key exchange: (\(\mathbf{{static}}_\mathrm{private}\),\(\mathbf{{static}}_\mathrm{public}\))

  • ECDSA key pair for server identity verification: (\(\mathbf{{sign}}_\mathrm{private}\),\(\mathbf{{sign}}_\mathrm{public}\))

Client Hello
  1. 1.

    Generate an initial ephemeral ECDH key (\(\mathbf{{c\mathtt{\_}init}}_\mathrm{private}\),\(\mathbf{{c\mathtt{\_}init}}_\mathrm{public}\)) and a client nonce \(\mathbf{{c}}_\mathrm{nonce}\).

     
  2. 2.

    Derive a temporary transport key and initialization vector (IV) using the server’s static key and the initial ephemeral key generated in Step 1 as follows.

    • \(\mathbf{{len}}_\mathrm{key}\)=16

    • \(\mathbf{{len}}_\mathrm{iv}\)=16

    • \(\mathbf{{share}}_\mathrm{temp}\)=ECDH(\(\mathbf{{c\mathtt{\_}init}}_\mathrm{private}\),\(\mathbf{{static}}_\mathrm{public}\))

    • \(\mathbf{{MS}}_\mathrm{temp}\)=HKDF\(_\mathrm{ex}\)(\(\mathbf{{c\mathtt{\_}init}}_\mathrm{public}\)||\(\mathbf{{c}}_\mathrm{nonce}\),\(\mathbf{{share}}_\mathrm{temp}\))1

    • \(\mathbf{{keyiv}}_\mathrm{temp}\)=HKDF\(_\mathrm{exp}\)(\(\mathbf{{MS}}_\mathrm{temp}\),“legy temp key”,\(\mathbf{{len}}_\mathrm{key}\)+\(\mathbf{{len}}_\mathrm{iv}\))

    • \(\mathbf{{key}}_\mathrm{temp}\)=\(\mathbf{{keyiv}}_\mathrm{temp}\)[0:15]

    • \(\mathbf{{iv}}_\mathrm{temp}\)=\(\mathbf{{keyiv}}_\mathrm{temp}\)[16:31]

     
  3. 3.

    Generate an ephemeral ECDH client handshake key (\(\mathbf{{c}}_\mathrm{private}\),\(\mathbf{{c}}_\mathrm{public}\)).

     
  4. 4.

    \(\mathbf{{c}}_\mathrm{public}\) and application data \(\mathbf {appdata}_\mathrm{client}\) are encrypted with \(\mathbf{{key}}_\mathrm{temp}\) and the client nonce \(\mathbf{{c}}_\mathrm{nonce}\) using the AES-GCM [6] AEAD cipher. The nonce is calculated by combining a client/server marker marker, a sequence number \(\mathbf{{num}}_\mathrm{seq}\), and \(\mathbf{{iv}}_\mathrm{temp}\) obtained in the handshake process.

     
  5. 5.

    Send the version \(\mathbf{{static}}_\mathrm{key version}\), client’s initial ephemeral key \(\mathbf{{c\mathtt{\_}init}}_\mathrm{public}\),2 client nonce \(\mathbf{{c}}_\mathrm{nonce}\) and encrypted data \(\mathbf{{data}}_\mathrm{enc}\) to the server.

     
Server Hello
  1. 1.

    Calculate the temporary transport key \(\mathbf{{key}}_\mathrm{temp}\) and IV \(\mathbf{{iv}}_\mathrm{temp}\) using the server’s static ECDH key \(\mathbf{{static}}_\mathrm{private}\) and the client’s initial ephemeral key \(\mathbf{{c\mathtt{\_}init}}_\mathrm{public}\) as follows.

    • \(\mathbf{{share}}_\mathrm{temp}\)=ECDH(\(\mathbf{{static}}_\mathrm{private}\),\(\mathbf{{c\mathtt{\_}init}}_\mathrm{public}\))

    • \(\mathbf{{MS}}_\mathrm{temp}\)=HKDF\(_\mathrm{ex}\)(\(\mathbf{{c\mathtt{\_}init}}_\mathrm{public}\)||\(\mathbf{{c}}_\mathrm{nonce}\),\(\mathbf{{share}}_\mathrm{temp}\))

    • \(\mathbf{{keyiv}}_\mathrm{temp}\)=HKDF\(_\mathrm{exp}\)(\(\mathbf{{MS}}_\mathrm{temp}\),“legy temp key”,\(\mathbf{{len}}_\mathrm{key}\)+\(\mathbf{{len}}_\mathrm{iv}\))

    • \(\mathbf{{key}}_\mathrm{temp}\)=\(\mathbf{{keyiv}}_\mathrm{temp}\)[0:15]

    • \(\mathbf{{iv}}_\mathrm{temp}\)=\(\mathbf{{keyiv}}_\mathrm{temp}\)[16:31]

     
  2. 2.

    Decrypt application data \(\mathbf {appdata}_{client}\) with \(\mathbf{{key}}_\mathrm{temp}\) and \(\mathbf{{iv}}_\mathrm{temp}\), and extract \(\mathbf{{c}}_\mathrm{public}\).

     
  3. 3.

    Generate an ephemeral key pair (\(\mathbf{{s}}_\mathrm{private}\),\(\mathbf{{s}}_\mathrm{public}\)) and a server nonce \(\mathbf{{s}}_\mathrm{nonce}\).

     
  4. 4.

    Derive the forward-secure (FS) transport key \(\mathbf{{key}}_\mathrm{FS}\) and IV \(\mathbf{{iv}}_\mathrm{FS}\) as follows.

    • \(\mathbf{{len}}_\mathrm{key}\)=16

    • \(\mathbf{{len}}_\mathrm{iv}\)=16

    • \(\mathbf{{share}}_\mathrm{FS}\)=ECDH(\(\mathbf{{s}}_\mathrm{private}\),\(\mathbf{{c}}_\mathrm{public}\))

    • \(\mathbf{{MS}}_\mathrm{FS}\)=HKDF\(_\mathrm{ex}\)(\(\mathbf{{c}}_\mathrm{nonce}\)||\(\mathbf{{s}}_\mathrm{nonce}\),\(\mathbf{{share}}_\mathrm{FS}\))

    • \(\mathbf{{keyiv}}_\mathrm{FS}\)=HKDF\(_\mathrm{exp}\)(\(\mathbf{{MS}}_\mathrm{FS}\),“legy temp key”,\(\mathbf{{len}}_\mathrm{key}\)+\(\mathbf{{len}}_\mathrm{iv}\))

    • \(\mathbf{{key}}_\mathrm{FS}\)=\(\mathbf{{keyiv}}_\mathrm{FS}\)[0:15]

    • \(\mathbf{{iv}}_\mathrm{FS}\)=\(\mathbf{{keyiv}}_\mathrm{FS}\)[16:31]

     
  5. 5.

    Generate and sign the handshake state using the server’s static signing key as follows.

    • state=SHA256(\(\mathbf{{c}}_\mathrm{public}\)||\(\mathbf{{c}}_\mathrm{nonce}\)||\(\mathbf{{s}}_\mathrm{public}\)||\(\mathbf{{s}}_\mathrm{nonce}\))

    • \(\mathbf{{state}}_\mathrm{sign}\)=ECDSA\(_\mathrm{sign}\)(state,\(\mathbf{{sign}}_\mathrm{private}\))

     
  6. 6.

    Application data \(\mathbf {appdata}_{server}\) is encrypted with \(\mathbf{{key}}_\mathrm{FS}\) and the nonce \(\mathbf{{s}}_\mathrm{nonce}\) using the AES-GCM AEAD cipher. The nonce is calculated by combining a client/server marker marker, a sequence number \(\mathbf{{num}}_\mathrm{seq}\), and the \(\mathbf{{iv}}_\mathrm{FS}\) obtained in the handshake process.

     
  7. 7.

    Send the ephemeral key \(\mathbf{{s}}_\mathrm{public}\), server nonce \(\mathbf{{s}}_\mathrm{nonce}\) and encrypted data \(\mathbf{{data}}_\mathrm{enc}'\) to the client.

     

Client Finish

  1. 1.

    Verify the handshake signature. If the signature is valid, proceed to the next step. If not, abort the connection.

     
  2. 2.

    Derive \(\mathbf{{key}}_\mathrm{FS}\) and \(\mathbf{{iv}}_\mathrm{FS}\) as follows.

    • \(\mathbf{{share}}_\mathrm{FS}\)=ECDH(\(\mathbf{{c}}_\mathrm{private}\),\(\mathbf{{s}}_\mathrm{public}\))

    • \(\mathbf{{MS}}_\mathrm{FS}\)=HKDF\(_\mathrm{ex}\)(\(\mathbf{{c}}_\mathrm{nonce}\)||\(\mathbf{{s}}_\mathrm{nonce}\),\(\mathbf{{share}}_\mathrm{FS}\))

    • \(\mathbf{{keyiv}}_\mathrm{FS}\)=HKDF\(_\mathrm{exp}\)(\(\mathbf{{MS}}_\mathrm{FS}\),“legy temp key”,\(\mathbf{{len}}_\mathrm{key}\)+\(\mathbf{{len}}_\mathrm{iv}\))

    • \(\mathbf{{key}}_\mathrm{FS}\)=\(\mathbf{{keyiv}}_\mathrm{FS}\)[0:15]

    • \(\mathbf{{iv}}_\mathrm{FS}\)=\(\mathbf{{keyiv}}_\mathrm{FS}\)[16:31]

     
  3. 3.

    Encrypt all subsequent application data using \(\mathbf{{key}}_\mathrm{FS}\) and \(\mathbf{{iv}}_\mathrm{FS}\).

     

2.2 Message End-to-End Encryption (E2EEP)

Client-to-Client Key Exchange. In order to be able to exchange encrypted messages, clients must share a common cryptographic secret. When a LINE client wishes to send a message, it first retrieves the current public key of the recipient. Next, the client passes its own private key and the recipient’s public key to the ECDH algorithm in order to generate a shared secret as follows.Message Encryption. The sender client encrypts a message with a unique encryption key and IV, and sends the encrypted message to the recipient client.
  1. 1.

    The encryption key \(\mathbf{{Key}}_\mathrm{encrypt}\) and IV \(\mathbf{{IV}}_\mathrm{encrypt}\) are derived from the shared secret calculated in the above process, and a randomly generate salt as follows.

    • \(\mathbf{{Key}}_\mathrm{encrypt}\)=SHA256(Shared Secret||salt||“Key”)

    • \(\mathbf{{IV}}_\mathrm{pre}\)=SHA256(Shared Secret||salt||“IV”)

    • \(\mathbf{{IV}}_\mathrm{encrypt}\)=\(\mathbf{{IV}}_\mathrm{pre}\)[0:15]\(\oplus \) \(\mathbf{{IV}}_\mathrm{pre}\)[16:31]

     
  2. 2.

    The generated key and IV are used to encrypt the message payload M using AES in CBC block mode.

     
  3. 3.

    The sender calculates a message authentication code (MAC) of the ciphertext C as follows.

    • \(\mathbf{{MAC}}_\mathrm{plain}\)=SHA256(C)

    • \(\mathbf{{MAC}}_\mathrm{enc}\)=AESECB(\(\mathbf{{Key}}_\mathrm{encrypt}\),\(\mathbf{{MAC}}_\mathrm{plain}\)[0:15]\(\oplus \) \(\mathbf{{MAC}}_\mathrm{plain}\)[16:31])

     
  4. 4.

    version,content type,salt,C,MAC\({{{\mathbf {\mathtt{{\_}}}}}}\)enc,sender key ID and recipient key ID are included in the message sent to the recipient.

     
  5. 5.

    The recipient derives the symmetric encryption key \(\mathbf {Key}_\mathrm{encrypt}\), and IV \(\mathbf {IV}_\mathrm{encrypt}\) as described above.

     
  6. 6.

    The recipient calculates the MAC \(\mathbf{{MAC}}_\mathrm{enc}'\) of the received cipher text, and compares it with the MAC \(\mathbf{{MAC}}_\mathrm{enc}\) value included in the message. If they match, the contents of the message are decrypted and displayed. Otherwise, the message will be discarded.

     

2.3 ProVerif

ProVerif is a model checking tool that performs automated security verification. To verify a security requirement of a protocol by ProVerif, we must formalize the cyptographic primitives, the protocol specification and the security requirement as input to ProVerif. Here, we briefly explain how to formalize these by using an example of a symmetric key encryption. For the detail of ProVerif, please see [5].

  1. 1.
    Define communication paths and cryptographic primitives
     
  1. 2.
    Define participant behaviors within the cryptographic protocol
     
  2. 3.

    Define public information, confidential information held in advance by each participant, and give it as input to participants.

     
A variety of properties can be analyzed by ProVerif, such as the correspondence assertions (i.e., whether event B occurred before the event A occurred), the reachability (i.e., whether a specific event occurred), and the observation equivalence (i.e., whether is able to analyze two processes that perform different computations but have the same run result).

3 Formalization of LINE encryption

In this section, we give our formalization of LINE Encryption in ProVerif.

3.1 Formalization of TEP

Rules for Signature. Define types of signature key and verification key required for digital signature, furthermore, the function spk that creates a verification key from the signing key. When a plaintext (bitstring) and a signing key are inputted, the function sign generates a signature. When a signature and a verification key are inputted, if the verification result is correct, define the checksign outputs true.
Rules for ECDH Key Exchange. Define types of the generator, exponents and the base point, and functions Ggen to convert the base point to the generator and sca to compute the scalar multiplication, and commutativity by equation.
Ruless for XOR. Define the function xor to compute the XOR of two inputs, and the property of XOR by six equation.
Parameter. Define key type, random number type, version type, and fixed values and word “legy temp key” as const.
Rules for AEAD. Define the function senc to encrypt a plaintext and the function sdec to decrypt a ciphertext, and the relationship between senc and sdec by reduc.
Declaration of Channel and Secret. Define the channel and secret information by free.
Type-Converting Functions. Define implicit functions to convert types for type adjustments of inputs of functions.
Verification of Forward Secrecy. Use reachability to verify forward secrecy. The attacker is passive, but he/she can obtain all static private keys of the server. Forward secrecy for client’s (resp. server’s) data require that the attacker cannot reach client’s (resp. server’s) application data. If the protocol has forward secrecy for client’s (resp. server’s) data, attacker(appdata1) (resp. attacker(appdata2)) will not happen. In other words, appdata1 (resp. appdata2) cannot be obtained by the passive attacker.
Verification of Server Authenticity. Using the correspondence assertions, we can verify authenticity for clients. We define event Client1 corresponding to encrypting Client’s secret message, and event Server1 corresponding to decrypting the secret message. If Server1 occurs, then Client1 must occur before Server1. It corresponds to client authenticity. Also, we define event Server2 corresponding to accepting digital signature verification, and event Client2 corresponding to completion of the session. If Client2 occurs, then Server2 must occur before Client2. It corresponds to server authenticity.
Client Subprocess. Define client’s actions.
Server Subprocess. Define server’s actions.
Main Process for Verifying Forward Secrecy. Generate the version ver, base point J, the ECDH private key stapr, and the signing key sprk. The ECDH public key stapu and public key of signature spuk are exposed in channel c. The client subprocess and the server subprocess are executed in parallel in phase 0. In order to verify forward secrecy, the ECDH private key stapr and the signing key sprk will be exposed in phase 1.

3.2 Formalization of E2EEP

Rules for ECDH Key Exchange. The process is described in Sect. 3.1, and we omit it.

Rules for AES-CBC. Define the function senccbc to encrypt a plaintext and the function sdeccbc to decrypt a ciphertext, and the relationship between senccbc and sdeccbc by reduc.
Rules for AES-ECB. Define the function sencecb to encrypt a plaintext and the function sdececb to decrypt a ciphertext, and the relationship between sencecb and sdececb by reduc.
Parameter. Define random number type, version type and fixed words “Key” and “IV” by const.

Rules for XOR. The process is described in Sect. 3.1, and we omit it.

Declaration of Channel and Secret. Define the channel and secret information.
Hash Function and Type-Converting Functions. Define the hash function and implicit functions to convert types for type adjustments of inputs of functions.
Verification of Secrecy and Authenticity for Replay Attack. Using the correspondence assertions, we can verify authenticity for clients. We define event Client1 which Client1 encrypts Client1’s secret message, and event Client2 which Client2 decrypts Client 1’s secret message. If Client2 occurs, then Client1 must occur only once before Client2. In order to verify replay attack, we use injective correspondence assertions inj-event to capture the one-to-one relationship. If it is a non-one-to-one relationship, it may happen that Client2 is executed twice or more, but Client1 is executed only once. In other words, it corresponds to a replay attack.
Client1 Subprocess for Replay Attack. Define client1’s actions.
Client2 Subprocess for Replay Attack. Define client2’s actions.
Main Process for Replay Attack. Generate the version ver, base point J, Client1’s ECDH private key c1cpr and client2’s ECDH private key c2cpr. The Client1’s ECDH public key c1cpu and client2’s ECDH public key c2cpu are exposed in channel c. Client1 subprocess and Client2 subprocess are executed in parallel.
Verification of Secrecy and Authenticity for Spoofing Attack. Using the correspondence assertions, we can verify authenticity for clients. Event accept, which the client1 believes that it has accepted to run the protocol with the client2 and the correct sender key ID. Event term, which the client2 believes that it has terminated a protocol run with the client1 with the correct sender key ID. When a spoofing attack occurs, a fake sender key ID is used by an attacker and the correspondence assertions cannot be correct execution.
Client1 Subprocess for Spoofing Attack. Define client1’s actions.
Table 1.

Verification results for TEP

Secrecy of app. data

Forward secrecy of app. data

Server

Client’s data

Server’s data

Client’s data

Server’s data

Authenticity

\(\checkmark \)

\(\checkmark \)

\(\times \)

\(\checkmark \)

\(\checkmark \)

\(\checkmark \) means that no attack is found. \(\times \) means that an attack is found.

Table 2.

Verification results for E2EEP

Secrecy of message

Authenticity

Reply attack

Spoofing attack

\(\checkmark \)

\(\times \)

\(\times \)

\(\checkmark \) means that no attack is found. \(\times \) means that an attack is found.

Client2 Subprocess for Spoofing Attack. Define client2’s actions.
Main Process for Spoofing Attack. Generate the version ver, base point J, Client1’s ECDH private key c1cpr, client2’s ECDH private key c2cpr, the sender key ID c1id and the recipient key ID c2id. The Client1’s ECDH public key c1cpu, client2’s ECDH public key c2cpu , c1id and c2id are exposed in channel c. Client1 subprocess and Client2 subprocess are executed in parallel.

4 Verification Results

In this section, we show the verification results. To summarize, we obtain the following verification results as in Table 1 for TEP and Table 2 for E2EEP. Next, we describe the found attack against forward secrecy for client’s data of TEP, and the found reply attack and spoofing attack for E2EEP.

4.1 Attack to Break Forward Secrecy for Client’s Data of TEP

  1. 1.

    An attacker who monitors channel c can knows the version, initial ephemeral ECDH public key \(\mathbf{{c\mathtt{\_}init}}_\mathrm{public}\), clint nonce \(\mathbf{{c}}_\mathrm{nonce}\) and ciphertext \(\mathbf{{data}}_\mathrm{enc}\), which the client sends to the server.

     
  2. 2.

    The attacker obtains the static private keys \(\mathbf{{static}}_\mathrm{private}\) and \(\mathbf{{sign}}_\mathrm{private}\).

     
  3. 3.

    By using \(\mathbf{{c\mathtt{\_}init}}_\mathrm{public}\) and \(\mathbf{{static}}_\mathrm{private}\), the attacker generates temporary transport key \(\mathbf{{key}}_\mathrm{temp}\) and initialization vector (IV) \(\mathbf{{iv}}_\mathrm{temp}\).

     
  4. 4.

    By using \(\mathbf {iv}_{temp}\) the attacker generates nonce1.

     
  5. 5.

    By using nonce1 and \(\mathbf{{key}}_\mathrm{temp}\), the attacker decrypts \(\mathbf {appdata}_\mathrm{client}\).

     

Therefore, the attacker can obtain application data from the client by using the static private key of the server without interrupting the communication between the client and the server. It corresponds to breaking forward secrecy for client’s data.

4.2 Replay Attack to E2EEP

  1. 1.

    An attacker can knows the static public information that the sender key ID sender key ID, ECDH public key \(\mathbf{{key}^{user1}}_\mathrm{public}\), the recipient key ID recipient key ID and ECDH public key \(\mathbf{{key}^{user2}}_\mathrm{public}\).

     
  2. 2.

    The attacker starts two sessions by initiating client2, and receives two ECDH public key \(\mathbf {key^{user2}}_\mathrm{public}\).

     
  3. 3.

    The attacker sends the client2’s ECDH public key \(\mathbf{{key}^{user2}}_\mathrm{public}\) to client1.

     
  4. 4.

    Client1 returns version, content type, salt, C, MAC, sender key ID and recipient key ID to the attacker.

     
  5. 5.

    The attacker sends version, content type, salt, C, MAC, sender key ID and recipient key ID to client2 in the first session.

     
  6. 6.

    The attacker sends version, content type, salt, C, MAC, sender key ID and recipient key ID send to client2 in the second session.

     

Since MAC is valid both for the first session and the second session, client2 completes both sessions. It corresponds to the reply attack.

4.3 Spoofing Attack to E2EEP

  1. 1.

    An attacker can know the static information that the sender key ID sender key ID, ECDH public key \(\mathbf{{key}^{user1}}_\mathrm{public}\), the recipient key ID recipient key ID and ECDH public key \(\mathbf{{key}^{user2}}_\mathrm{public}\).

     
  2. 2.

    The attacker starts a session by initiating client2, and receives ECDH public key \(\mathbf {key^{user2}}_\mathrm{public}\).

     
  3. 3.

    The attacker randomly generates a fake sender key ID sender key ID’.

     
  4. 4.

    The attacker sends client2’s ECDH public key \(\mathbf{{key}^{user2}}_\mathrm{public}\) and the recipient key ID recipient key ID to client1.

     
  5. 5.

    Client1 returns version, content type, salt, C, MAC, sender key ID sender key ID and recipient key ID recipient key ID to the attacker.

     
  6. 6.

    The attacker sends version, content type, salt, C, MAC, the fake sender key ID sender key ID’ and recipient key ID recipient key ID to client2.

     

Since MAC does not depend on the sender key ID, client2 accepts MAC if the sender key ID is replaced. Hence, the attacker can impersonate the fake sender to client2. It corresponds to the spoofing attack.

5 Summary

We verified the security of LINE Encryption (Version 1.0), (i.e., the TEP and the E2EEP) by ProVerif. In LINE documents [1, 2], it is claimed that the TEP satisfies forward secrecy (i.e., even if the static private key is leaked, security of encrypted application data before leakage is guaranteed). However, it is not clear if both client’s and server’s data must be protected. We clarify actual forward secrecy of the TEP by showing an attack to break forward secrecy for client’s data. In addition, we found a replay attack and a spoofing attack of E2EEP.

Since all known attacks (the reply attack and the spoofing attack) and a new attack (breaking forward secrecy for client’s data) are found, our result shows usefulness of ProVerif to verify security of messaging protocols like LINE. Finally, we note that the found attack for forward secrecy for client’s data is not serious because the LINE security team says that client’s data does not contain any sensitive information in the current implementation of LINE encryption. However, it may be potential vulnerability if an engineer use the TEP for another implementation.

Footnotes

  1. 1.

    In [1], it is described as \(\mathbf{{MS}}_\mathrm{temp}\) = HKDF\(_\mathrm{ex}\)(\(\mathbf{{c}}_\mathrm{public}\)||\(\mathbf{{c}}_\mathrm{nonce}\), \(\mathbf{{share}}_\mathrm{temp}\)). However, it is a typo. The authors confirmed the typo to the LINE Security Team.

  2. 2.

    In [1], it is described as to send \(\mathbf{{c}}_\mathrm{public}\). However, it is a typo. The authors confirmed the typo to the LINE Security Team.

References

  1. 1.
  2. 2.
    LINE Encryption Status Report, 24 August 2018. https://linecorp.com/en/security/encryption_report
  3. 3.
    Espinoza, A.M., Tolley, W.J., Crandall, J.R., Crete-Nishihata, M., Hilts, A.: Alice and Bob, who the FOCI are they?: analysis of end-to-end encryption in the LINE messaging application. In: FOCI @ USENIX Security Symposium (2017)Google Scholar
  4. 4.
    Isobe, T., Minematsu, K.: Spoofing attack and forgery attack against LINE’s end-to-end encryption. In: SCIS 2018 (2018). (in Japanese)Google Scholar
  5. 5.
    Blanchet, B., Smyth, B., Cheval, V., Sylvestre, M.: ProVerif 1.98. http://prosecco.gforge.inria.fr/personal/bblanche/proverif
  6. 6.
    McGrew, D., Viega, J.: The Galois/Counter Mode of Operation (GCM). Manuscript, May 2005. NIST websiteGoogle Scholar

Copyright information

© Springer Nature Switzerland AG 2018

Authors and Affiliations

  1. 1.Ibaraki UniversityIbarakiJapan

Personalised recommendations