Approov Dynamic Pinning - An Independent View

Why Does Approov Have Dynamic Pinning At All? 

In the early days of Approov, we expected that most customers would pin their API connections as a matter of course. Traditional static TLS/SSL pinning is good security hygiene and makes perfect business sense. It wasn’t long before the real world kicked in and we found not only that many customers did not pin their connections, but they actively didn’t want to. We even had a situation where the Dev group implemented pinning but their DevOps team wouldn’t allow them to deploy it.

We were puzzled by this but, as we dug in, we discovered that there was a real fear of messing up the pinning and/or the management of certificates and there were a few  high profile examples of mobile apps getting ‘bricked’ in the process of having their certificates updated due to poor implementation. It occurred to us that we might be able to help by leveraging our experience but also some of Approov’s in-built capabilities, in particular our over-the-air updating features for apps in the field. 

The Rakuten blog explains it very well but if you want to read all the details about Approov dynamic pinning feature, you can find it in our user documentation here. Have a read and if you have comments or questions, please get in touch.

The Approov And/Or SafetyNet Question 

Finally, the blog also touches on the fact that Approov might be considered as an enhancement to the protection afforded by Google’s SafetyNet API. We often have this conversation with customers and potential customers, and we have written about it before. 

It’s not wrong to think of Approov this way, but it should be noted that there are more differences than similarities. The blog notes a number of things we do in addition to SafetyNet (like supporting iOS!), but we would also point out that it is important to consider the server side complexity of using SafetyNet. This is something we have been looking at ourselves very recently. 

Specifically, for SafetyNet users to get their attestation quota increased to production levels they have to show that they are doing everything to avoid excessive calls to the SafetyNet service. What this means for you is:

• You need your server to remember the state from prior SafetyNet calls to avoid using up quota by making requests every time the app starts. Getting a SafetyNet token also takes several seconds on each device so you will also want to avoid a delay like this which will be perceptible to app users.
• You need to deal with situations in which a SafetyNet token can't be obtained, if for instance the service is down.
• You need to generate suitable nonce values on the server to prevent replay.
• You may need to deal with devices that fail SafetyNet, and this can be problematic in many markets which need to allow rooted devices. For example, financial services markets may ban rooted phones but retail markets will most likely allow them. In such failure cases the certificate hash information is not provided so there is little useful information in the SafetyNet token.
• You need to handle the fact that certain devices and markets don't have Google Play Services (e.g. newer Huawei devices) so you need some kind of attestation fallback implementation for those situations.

As we have said before Approov and SafetyNet do complement each other and there are situations where it makes sense to have both solutions working in tandem. We have already formalized such an integration with Apple’s DeviceCheck API, which we have also written about, and now offer as a feature within Approov as you can see here.

P.S. SafetyNet support inside Approov is coming very soon!