Ensuring device and app integrity and protecting service requests: LINE device attestation service (2)

The original article was published on August 30, 2024.

Hello. We are Eun Chan Kim, Jong Min Kim, Gi Beom Gwon, Euiyub Jung, and Wonyeong Heo from the Auth & Account Dev team. The Auth & Account Dev team is responsible for backend development related to accounts and authentication for LY Corporation group services.

In this post, we will introduce our experience applying device attestation to our company's services, following the introduction by the Security R&D team in Ensuring device and app integrity and protecting service requests: LINE device attestation service (1), and discuss future development directions.

Device attestation service development process

The Auth & Account Dev team and the Security R&D team have continuously collaborated to ensure that users can use our company's services more safely. As a result, the LINE app introduced a feature to log in without a password (reference: FIDO at LINE: A First Step to a World Without Passwords), and the device attestation service introduced in this article was also implemented through close collaboration with the Security R&D team.

The device attestation service was developed to provide a means to prevent service abuse as cases of exploiting our company's services for account hijacking, spamming, phishing, fraud, etc., increased. The Security R&D team designed the device attestation and completed the PoC (proof of concept) implementation, and the Auth & Account Dev team shared the PoC implementation to develop the backend for actual service application. Thanks to the design using the FIDO2 WebAuthn object, a standard for passwordless authentication, we were able to complete the implementation smoothly.

The device attestation feature began to be applied to the LINE Android and iOS apps starting in December 2023. To apply the feature stably, it was gradually deployed by country, and by May 2024, it was fully deployed to all countries where the LINE app is serviced. As a result, we were able to observe the differences in device attestation results between the Android and iOS platforms. We will share those observations.

Device attestation application - LINE Android app

To smoothly implement the device attestation feature on the Android platform, a trusted execution environment and an Android operating system of a certain version or higher are essential. Devices released by various manufacturers such as Samsung, Xiaomi, vivo, OPPO, etc., have different hardware components and supported Android versions depending on the model. Therefore, even within the same manufacturer, there coexist models that support the device attestation feature and those that do not.

After deploying the device attestation feature, we identified five major causes of failure in the LINE Android app, listed in order of frequency:

• Failure in certificate chain verification: When the verification of the x.509 certificate chain within the attestation object fails
• attestationSecurityLevel set to Software: When running on a device with low security (no hardware-based key storage) or an emulator
• When the LINE app is tampered with: When the LINE app is modified, and the package name and signature differ from the official LINE app
• When the device is rooted: When the device is rooted, and the root of trust in the x.509 certificate extension is not normal
• When a revoked certificate is used: When a certificate included in the certificate chain is revoked by Google due to reasons such as private key leakage (reference: Certificate revocation status list)

Let's take a closer look at each case.

Failure in certificate chain verification

When verifying the x.509 certificate chain within the attestation object, not only the signature of each certificate but also various information recorded in the certificate extension is checked. Therefore, even if the certificate signature is correct, verification fails if some information is incorrect.

Cases of failure in certificate chain verification can be divided into those suspected of abuse and those suspected of being normal users, with the following examples of chain verification failure in each case:

• Suspected abuse cases
  • Failure in certificate signature verification: When the signatures of the certificates included in the certificate chain are incorrect
  • Untrustworthy root certificate: When the root certificate is not issued by Google
• Suspected normal user cases
  • When the keyCertSign bit or CA bit is not set to 1 (reference: RFC 5280 - Basic Constraints)
  • When the certificate validity period is set to the past
    • According to RFC 5280, if the year expressed as a two-digit "YY" is 50 or greater, it is interpreted as 19YY, so even if the certificate issuer intended to input "69" for 2069, it is interpreted as 1969, resulting in certificate verification failure
    • If the certificate validity period is simply set to "0", it is interpreted as January 1, 1970, resulting in certificate verification failure
  • When the Issuer of the certificate is incorrect
    • The Issuer value of the certificate should match the Subject value of the upper certificate that signed it, but in some certificates, the Issuer value only includes part of the upper certificate's Subject value

Need for separate verification criteria

After reviewing the data of certificate chain verification failures with the Security R&D team, it was found that most cases, except for certificate signature verification failures and untrustworthy root certificates, were suspected to be normal users. To reduce false negatives in device attestation, it is important to reduce cases where attestation fails even when using a normal device. Therefore, we decided to apply separate criteria for cases suspected to be normal users.

To apply new verification criteria, the Security R&D team created a separate implementation based on Java's CertPathValidator, and our team collected models suspected to be normal users but failed device verification to review whether separate criteria could be applied. For confirmed device models, separate criteria were applied, while existing criteria were applied to other device models to verify the certificate chain, reducing the number of Android devices failing certificate chain verification by one-tenth.

AttestationSecurityLevel set to Software

For this case, please refer to the detailed explanation in Part 1's Detecting potentially untrustworthy execution environments.

LINE app tampered

In the case of Android, APK files can be decompiled, the app's functionality changed, and then recompiled. If the LINE app is tampered with in this way, the AttestationApplicationId can be verified to check for app tampering. The LINE app tampering cases confirmed through device attestation in actual service were mainly two types.

Installing multiple instances of the same app on one device using dual apps

Searching for "Dual apps" on Google Play reveals many apps that allow multiple installations of the same app on one device. One method these apps use is to change the package name of the APK file and recompile it. Analyzing the data coming through the LINE app's device attestation feature, we confirmed that more than 10 dual apps are being used in the market.

Malicious use of tampered LINE app

This refers to attempts to change the operation of the LINE app itself, beyond simply installing multiple instances of the LINE app through dual apps. It is the type that should be most cautious about, as a user with malicious intent can use a modified LINE app for criminal activities. Tampered apps can pose the following risks:

• Personal information leakage
  • Tampered apps can collect and transmit sensitive personal information of users without permission, and such collected personal information can be used for other crimes.
• Service disruption
  • Tampered apps can disrupt the normal operation of the LINE app service, causing issues such as server overload or service quality degradation. This can inconvenience other users and damage the trust in the LINE app service.

Using tampered apps is a violation of the LINE app's terms of service and may result in service restrictions. In particular, using tampered apps for financial fraud, identity theft, data leakage, etc., can lead to severe criminal penalties. To prevent the use of tampered apps, please ensure to install the LINE app through official channels such as Google Play or Apple App Store.

Device rooted

In Android, root access can be obtained using various rooting frameworks. With root access, specific method calls of apps can be intercepted, and desired code can be executed without modifying the app, allowing desired operations to be performed. This corresponds to the items explained in Part 1's Detecting potentially untrustworthy execution environments.

• deviceLocked set to False
• verifiedBootState not set to Verified

Revoked certificate used

This occurs when a certificate revoked by Google due to reasons such as private key leakage is used in the certificate chain of the attestation object. In this case, the contents of the certificate chain cannot be trusted, as an attacker may have created the certificate chain using the leaked certificate private key. For more details, please refer to Part 1's Measures against attestation key leaks.

Device attestation application - LINE iOS app

Apple maintains a consistent direction when developing iOS and iPhone, designing most features to be compatible with all iPhone models and regularly updating iOS to support the latest iOS version on most iPhone models. Thanks to this, LINE iOS app users are achieving a device attestation success rate close to 100%.

LINE app tampered

Although the device attestation success rate on iOS is close to 100%, some cases of failure due to LINE app tampering were confirmed. In iOS, jailbreaking is required to obtain root access to tamper with apps. Since no jailbreaking method for recently released iPhones has been publicly disclosed, it is highly unlikely that a general user tampered with the LINE iOS app. Additionally, even if root access is obtained on iOS to tamper with the LINE iOS app, the rpIdHash value introduced in Part 1's Attestation object will change, allowing confirmation of app tampering.

Device attestation application results

Summarizing the content introduced earlier, while it was expected that various types of device attestation would be observed on Android, the actual types of device attestation failures identified were more than expected, whereas iOS was more unified than anticipated.

Through this application of the device attestation service, we were able to confirm various types of device attestation in the real world and quantify the scale of each type.

Future directions

Now, we will introduce how we plan to utilize the device attestation applied to the service in the future.

Tracking and observing potentially risky types

We plan to observe usage patterns related to the following cases, which may pose potential risks, and utilize them for anti-abuse:

• When directly calling APIs to mimic the LINE app without using the app
• When the app is tampered with through rooting, etc.

Utilizing Apple's Risk Metric field

Apple's receipt field includes fields such as App ID, Attested Public Key, Client Hash, Token, Receipt Type, Creation Time, Risk Metric, Not Before, Expiration Time, etc., and the Risk Metric field can be used to indirectly assess the abnormality potential of the device.

Risk Metric field

Although unlikely, if root access is obtained without directly modifying the device's operating system through application and kernel vulnerabilities, device attestation can be bypassed (reference: Part 1's Measures to prevent device attestation bypass). In this case, the integrity at the boot level is not compromised, allowing the attacker to bypass or manipulate the attestation and assertion process. The Risk Metric field can be utilized in such situations.

According to the related documentation provided by Apple, the Risk Metric field value is the number of attestations that occurred on the device in the past month. If multiple instances of the LINE app are running or reinstalled multiple times through obtained root access, attestations are executed frequently, increasing the Risk Metric value. Therefore, if the Risk Metric field value exceeds a certain threshold, it is highly likely that the user or device is not a normal user or use case.

We collected the Risk Metric field values of iOS users and investigated the correlation with abnormal users detected by the anti-abuse system. As a result, we found that users with Risk Metric field values exceeding a certain threshold had a significantly higher probability of being abnormal users, and we confirmed that abnormal users who could not be immediately detected by the existing anti-abuse system could be quickly detected through this. Having statistically confirmed the potential for utilization, we plan to use the Risk Metric field value as a new indicator in the existing anti-abuse system.

Applying to services requiring high security levels

We provide various means to easily integrate the device attestation feature into other family services besides the messaging service. By using this, services requiring high security levels, such as finance or healthcare, where privacy protection is crucial, can easily and quickly adopt the device attestation feature to check for app or OS tampering.

Currently, work is underway to apply device attestation to our company's banking and payment services. Beyond simply checking the success of attestation, we plan to bind API parameter values to assertions in important functions such as payments and remittances (reference: Part 1's Binding API to assertions) to verify that the information has not been tampered with due to intermediate proxy servers or other external factors. This will protect sensitive financial transactions and maintain the integrity of the service, providing users with a more trustworthy financial environment.

Conclusion

Over two parts, we introduced the technical principles of device attestation, the process of applying the device attestation feature to the LINE app service, and future plans. Device attestation is expected to gradually expand to other services of our company, further enhancing the trust level of the service.

We would like to take this opportunity to sincerely thank the Security R&D team, Account Product App Dev 1 team, Platform Product Management team, Developer Platform Dev team, and LINE BK team for their great help in the process of applying device attestation. Thank you for reading this long article.