Author’s brief introduction

Henryye, Ye Xuan, from TENCENT WeChat enterprise group, is mainly responsible for TENCENT open source projects TENCENT SOTER (making address: https://github.com/Tencent/soter, click here to read the full text Also can directly access) biometric authentication platform development, maintenance and operation.

When it comes to fingerprint payments, what do you do?

If one day, product manager arrange you to do fingerprint payment, and want the next version on, what will you do?

If it is the product eldest brother, from the station below a nail knife on his neck, let him kneel in the corner to sing conquest;

If it’s a product girl, let her buy you coffee and talk about it. “Choose world peace, it’s easier than paying with a fingerprint.”

Of course, the imagination is still too gentle. Those who have really done the fingerprint payment project will often recall the nightmare of fingerprint payment demand in the middle of the night. In the dream, I will add drama to myself and tear the product manager by hand.

Product owners may protest: “Fingerprint payment, ready-made interface on the client, why not?”

Does the system interface work?

Ever since the first fingerprint-enabled iPhone 5S went on sale in 2013, the term “fingerprint payment” has been popping up frequently in product PM-lists. However, devices prior to Android 6.0 did not have a unified fingerprint authentication interface. This means that if you’re a frustrated programmer, you’ll have to adapt your own fingerprint schemes and maintain vendor interface updates. Given the fragmentation of the Android market, it’s Impossible Mission to cover all models. In fact, in the early stage of the project, wechat tried to connect huawei Mate 7 and Honor 7, and it only took three months! This investment is clearly not worth the cost.

Fortunately, starting with Android 6.0, the system provides a standard FingerprintManager. This is a big plus for programmers doing similar needs to see a silver lining in the dark, because the interface seems so easy to use. No matter what brand of phone you have, Android 6.0 or newer will enable fingerprint authentication as follows:

FingeprintManager mFingeprintManager = …

mFingeprintManager.authenticate(null, mCancellationSignal, 0 , new AuthenticationCallback(){… }, null);

The design itself is simple:

System Authentication Interface

It looks perfect, as if you didn’t have to develop a version to implement fingerprint payment in an hour, right?

If you root your phone, you can change the authentication result from false to true. If you root your phone, you can change the authentication result from false to true.

Let’s try another way: Root’s phone will not allow fingerprint payment.

Silly boy, how can you tell if the phone is root? Isn’t the value also obtained through the Android interface? This value can be changed as well.

Payment security should not be taken lightly. Once something goes wrong, it is a major accident. Fortunately, Google is aware of this problem and has enhanced the Fingeprprint interface with the Fingerprint authentication interface. (See Google Sample for the code.) https://github.com/googlesamples/android-FingerprintDialog) :

This diagram may seem obscure, but the principle isn’t that hard: Google, since Android 6.0, has allowed users to generate a pair of asymmetric keys in their apps, storing the private key in TEE (what is TEE? More on that later), no one, including the app itself or even the Android system, can obtain the private key unless the user uses fingerprint authorization, signs or encrypts incoming data, and then outputs ciphertext. In this case, you can use the key signature – check mechanism (small white do not understand what is the signature check? A correct signature can be generated only after the user uses a fingerprint to sign the signature. In this way, link security is ensured.

The design is clever, but Google is tricky: if a hacker intercepts the request at the time the key is generated and replaces it with his own key, then the whole system’s design collapses when the hacker later signs and encrypts it using the same key.

Hack motioned

There is another problem. If you only return true/false, you can pay as long as your fingerprint is entered into the device. This can be a bankcard nightmare for parents with children. To make matters worse, on Android devices (and iOS, for that matter), a new fingerprint can be logged in just by knowing the lock password. If the payment background directly trusts the fingerprint authentication result, the payment password, which is very secret, is reduced to the level of screen-lock password. In this way, no matter how strict the risk control strategy is made by the payment background, according to the barrel principle, the whole system is fundamentally inconsistent with the payment security.

At that time, of course, also have similar to FIDO certification alliance (link: https://fidoalliance.org/), but the whole process is too complicated, even for application background into the SDK. Moreover, the central service authority of similar schemes is too high, so that key indicators such as the number of payments and the number of users will be known, so they cannot be used. And the number of supported devices is too few, and there is no access power.

After studying these, it was found that none of them could be used directly, and the situation was awkward. What if I don’t have the right wheels?

Can you make wheels without wheels?

Let’s go back to Android’s fingerprint interface design:

  • Convenient fingerprint interface, perfect!

  • The creative combination of fingerprint module and key module makes it possible for user authorization to sign, perfect!

So what is Google not doing?

  • Without a trusted trust root, the key can be easily replaced.

  • The user who authorized the authentication request cannot be obtained from the authentication result.

At the same time, we realize that there is a lack of a unified, secure and easily accessible authentication standard in the hundred-billion-dollar market of biometric authentication. Wechat has such a demand, and other applications are bound to do the same. Wechat has the ability to solve these problems and realize its own business needs, and hopes to replicate its successful experience. In this case, wechat is duty-bound to take this opportunity to establish a biometric authentication standard and provide a biometric authentication platform, which is the origin of SOTER.

If SOTER is implemented as a standard, then in addition to the system interface defects just described, system design needs to consider:

  • The background does not store any sensitive information, including symmetric keys, asymmetric keys and private keys, nor can it transmit or store users’ ecological features (such as fingerprint patterns) in any form to prevent the application background from being destored.

  • If there is background interaction, the core business privacy of the application party will not be exposed, such as the number of authentication times and service opening times;

  • Application access threshold is low, the client does not need to integrate heavyweight SDK, background does not need to integrate SDK;

  • Simple and easy to use, third-party applications only need to operate the upper interface, without complex low-level development.

How do I generate a trusted trust root (device root key)?

The importance of trust roots has been explained previously. If a system relies on key signatures, it is possible to build a secure trust model by having a trusted root key. However, if a phone produces its root key (ATTK) after it leaves the factory, there is plenty of time for a hacker to replace it. Therefore, it must not be possible to generate the root key in the normal way. Therefore, we have a bold idea: directly cooperate with the manufacturer to generate the device root key on the production line before the device leaves the factory, and the public key is transmitted to the wechat key service — TAM through the service of the manufacturer. Although this idea has a large transformation for manufacturers, we have directly cooperated with upstream industry chain (Qualcomm, MTK, etc.) to develop a set of unified solutions and production line tools, and successfully persuaded manufacturers to make minimal transformation for production lines. It’s tough, but we did It!

Device root key flow

  1. On the production line, the vendor delivers the command for generating the root key of the device.

  2. TEE generates a pair of rSA-2048 asymmetric keys unique to the device. The private key is stored in the RPMB area of the device and can not be read by any manufacturer or application party (including wechat and device manufacturer). The public key and device ID are exported.

  3. The public key and device ID are uploaded to the manufacturer’s server, and then transmitted to the wechat public platform through the public platform security interface.

  4. The wechat public platform transmits the public key and device ID to the wechat TAM server.

Here again, we meet our old friend TEE (Trusted Execution Environment), a term we will use many times. If you want to see the detailed introduction, you can refer to here (link: https://en.wikipedia.org/wiki/Trusted_execution_environment). Of course, I’m sure most of you, like me, just want a visual explanation. Simply put, you have a separate environment on your phone from an operating system like Android. There is currently no effective method to crack this environment, that is, even if the Root Android system, can not crack the data in TEE. If the whole phone is a house, the Android operating environment is the living room, TEE is your safe. Imagine how beautiful it would be if all data were stored in TEE and key operations were performed in TEE. In this case, of course, all sensitive data coming out of TEE must be signed with a trusted key.

With the device root key, the authentication chain construction logic is much clearer: in the form of the key chain, it is ok to use the authenticated key to authenticate the unauthenticated key!

How to construct a complete certification process?

With a methodology, implementation becomes simple.

However, there is still a question to consider: how many layers of keys are needed? If the number of key layers is small, they need to go to the central service (wechat TAM) every time to check the signature. For third-party applications, they will be more worried about revealing their business logic. The number of key layers increases the transmission complexity and failure rate. After many discussions, SOTER decided to use the three-level key. In addition to the device root key prefabricated on the production line, the application key (only one pair is required within each application life cycle) and the service key (one pair is required for each service) were defined. This proved to be a wise choice: it kept the flow smooth while keeping the app’s business-critical privacy intact. Why is that? To look down.

architecture

SOTER architecture diagram

We love Google’s fingerprint and key module interface design, so we worked with vendors to quickly implement the entire superarchitecture by adding patch packages on top of it.

Prepare the application key (ASK)

Prepare the flowchart for applying the key

  1. When the application is started for the first time or before the service is used for the first time, it requests to generate the device root key.

  2. After the key is generated, the private key is protected by TEE and stored encrypted.

  3. The public key, device ID and other related information are directly signed by the device key private key in TEE and returned to the application.

  4. The application transmits the public key information and signature to the application background.

  5. The application background requests visa inspection through the background interface of wechat public platform;

  6. TAM uses the corresponding device key to check the public key, which is returned to the application after passing.

  7. The application background stores the corresponding application public key.

Example of a string transferred to the background:

Note 1: The device is stored in TEE after leaving the factory. This value increases with each SOTER operation, and the playback factor is stored in the background. If the background detects that the anti-replay factor of the request is smaller than the recorded value, the request is considered illegal.

Note 2: Originally intended as a UNIx-like system user ID, in Android system, generally each application has a UID, which can be used to distinguish applications and permission control. Note The application key and service key are different depending on the UID. In the background, the UID and CPU_ID should be used to distinguish the key.

Preparing the Service Key (Auth Key)

Prepare the service key flow diagram

  1. When the application initiates a service (such as fingerprint payment), it requests to generate a service key. At the same time, the private key cannot be used unless the user’s fingerprint is authorized.

  2. After the key is generated, the private key is protected by TEE and stored encrypted.

  3. The public key, device ID and other related information are directly signed by the application key and private key in TEE and returned to the application.

  4. The application transmits the public key information and signature to the application background.

  5. The application background uses the corresponding application key to check the public key, and there is no need to request the wechat TAM center service.

  6. After a successful verification, the application background stores the corresponding service key.

The meaning of transmitted data and application key is the same as that of the application key.

The certification process

Schematic diagram of authentication Process

  1. The client requests the background to obtain the challenge factor;

  2. After obtaining the challenge factor, send the challenge factor to TEE, prepare signature structure, prepare signature;

  3. The application requests user fingerprint authorization.

  4. After fingerprint authorization, the user directly transmits the index of the fingerprint used in the authentication to the key module, and uses the service key and private key to sign the challenge factor and the index in TEE.

The application obtains the original string and signature string and transmits them to the application background. The application background uses the corresponding service key to check signatures. If successful, the authentication or opening request is valid.

Transfer to background string example

Does the process meet requirements?

The wheel is built, and we go further and further on the road of self-appreciation. Looking back, did SOTER meet our requirements?

  • Adding a trust root: SOTER transfers the device root key in the factory environment to ensure the security of the trust root.

  • Distinguishable fingerprint: After authentication, TEE directly transmits the fingerprint ID used this time internally, enabling the application to freely choose whether to distinguish fingerprints;

  • The background does not store sensitive information: the background only stores device IDS and public keys, so that even if the background design is bad, it is no longer afraid of unstoring;

  • Background interaction does not expose privacy: the original application key ensures that service opening and service usage do not need to go through the application server;

  • Background does not need SDK: background uses mature public platform interface, rich documentation, low learning cost, not to mention SDK.

Of course, our solution has been recognized by major manufacturers and chips. In a short period of time, it has been supported by hundreds of millions of devices, covering almost all mainstream mobile phone brands. Therefore, application access does not need to consider whether multi-device adaptation is needed or whether adaptation is insufficient. Incidentally, we support vivo and OPPO’s 5.X fingerprint models, even though the system itself does not have a unified fingerprint interface.

However, there are two final points that have not been done:

  • The client access threshold is low, and the client SDK is lightweight and does not even need SDK.

  • Easy to use, the client without deep development can be used.

 

The only solution to both problems is open source!

What have we opened source?

In order to meet different scenarios of different applications, we open source:

  • SOTER client core interface SOter-core: indicates the direct interface for SOTER internal operation keys and invocation fingerprints. The SIZE of the SDK is about 40KB, and the increment in the size of the installation package is negligible.

  • SOTER client process encapsulation interface SOter-wrapper: Encapsulates specific SOTER processes and adaptive models. The SIZE of the SDK is about 70KB, and the increment of the installation package size is less;

  • Quick start client demo, from scratch, to help you realize fingerprint payment in just a few lines of code;

  • Complete client documentation and background interface documentation;

  • Complete principle analysis and quick start.

All this, all in TENCENT SOTER (making address: https://github.com/Tencent/soter, click here to read the full text Also can directly access).

How fast can I use SOTER? If you only need to do something with a low security requirement like a lock screen, just:

  • Add gradle dependencies

In your project’s build.gradle, add the SOTER dependency

dependencies {    

.

The compile ‘com. Tencent. Soter: soter – wrapper: 1.3.8’

.

}

  • Declare permissions

Add fingerprint permission to androidmanifest.xml

<uses-permission android:name=”android.permission.USE_FINGERPRINT”/>

  • Initialize the

The initialization process is used to generate basic configurations and check device support status only once in the application declaration period. You can choose to initialize it in Application onCreate() or before using SOTER.

InitializeParam param = new InitializeParam.InitializeParamBuilder()

.setscenes (0) // The scene value is a constant, which can be used for key generation or fingerprint authentication

.build();

SoterWrapperApi.init(context, new SoterProcessCallback

() {… }, param);

  • To prepare the key

You need to generate the relevant key before using fingerprint authentication

SoterWrapperApi.prepareAuthKey(new SoterProcessCallback

() {… },false, true, 0, null, null);

  • Fingerprint Authentication

After the key is generated, you can use the encapsulation interface to invoke the fingerprint sensor for authentication.

AuthenticationParam param = new AuthenticationParam.AuthenticationParamBuilder()

  .setScene(0)                                    

  .setContext(MainActivity.this)                                    

  .setFingerprintCanceller(mSoterFingerprintCanceller)

  .setPrefilledChallenge(“test challenge”)                                    

.setSoterFingerprintStateCallback(new SoterFingerprintStateCallback() {… }).build();

SoterWrapperApi.requestAuthorizeAndSign(new SoterProcessCallback

() {… }, param);

Of course, if you want to implement fingerprint payment, fingerprint login and other high security scenarios, there are a few other things to do, as shown in our sample code (link: https://github.com/Tencent/soter/tree/master/soter-client-demo) and security access documents (link: https://github.com/Tencent/soter/wiki/%E5%AE%89%E5%85%A8%E6%8E%A5%E5%85%A5).

SOTER (making address: https://github.com/Tencent/soter, click here to read the full text After open source can also be accessed directly), there have been multiple applications, including micro Banks have access to these applications access for no more than one version. The scenarios also range from fingerprint payment to fingerprint login and fingerprint unlock. If you’ve used it, say yes.

So, let’s go back to the opening scene: “We’re going to make fingerprint payments, and in the next version…” You already know how to do it