Digitally signed code guarantees that a mobile app executable has not been modified since it was signed. Code signing is also used to confirm the identity of the publisher (such as a company or software developer) that created the mobile app.
Mobile app signing, also known as code signing, is the process that is used to digitally sign a mobile app.
Historically, app developers and publishers code signed mobile apps to protect apps from being tampered with or altered, and to establish differentiation from pirated apps. With code signing, the mobile app has a digital signature that can be used to verify its authenticity.
Code signing provides a layer of trust by using a cryptographic hash to validate authenticity and integrity of the mobile apps. This hash is the code signing certificate, which is a digital certificate that contains information that identifies the entity and is issued by a certificate authority.
The code signing certificate binds the identity of the app’s publisher to a public key that is mathematically related to a private key pair. This public key should be traceable back to a trusted certificate authority, preferably using a secure public key infrastructure.
This public key infrastructure enables the secure electronic transfer of information and, in the case of mobile apps, is required when a more rigorous authentication method is needed to confirm the connection between an app and its creator. The integrity of code signing relies on publishers preventing unauthorized access to their private keys.
Mobile app developers intimately understand the development lifecycle and release process, which includes app signing. Despite this familiarity and having to regularly sign apps with a code signing certificate, developers still struggle to get code signing right. Delays in app release due to signing issues is a common occurrence.
However, app signing is now no longer just performed by developers. The responsibility to ensure apps have the correct digital signature is now falling to IT operations because apps often need to be modified after the development process is ‘complete.’
There are many reasons why this modification is needed, including changes required for the backend infrastructure, or addition of security controls, performance management, or analytics functionality overlooked during the initial code build. Maybe a company’s IT operations team needs to deploy an app to different places, such as a private app catalog instead of a public app store. Perhaps the company may have acquired the app from a third-party independent software vendor (ISV) that doesn’t provide the needed functionality. For example, app-level security controls that work with the company’s unified endpoint management (UEM) solution may need to be added. Having app-level security controls enables a company to retain control over data in the app even if the app is used on mobile devices that are not managed by the company. Or a company may instrument a mobile app with an analytics library so that usage data can be collected. Aggregating usage data across all end users and analyzing it provides insights to make improvements to the app.
Any such modification requires the app to be code signed again, and the responsibility for signing the app with a code signing certificate increasingly falls to IT operations because sending it back to developers will cause uncontrollable delays, especially if it has to be re-signed by a third-party vendor. IT operations teams are not intimate with the app development lifecycle and release process, which makes the generation of signed code challenging. They are infrequently involved with these activities and, as a result, need to relearn the processes continually, such as what to do with a code signing certificate. Often, ‘documentation’ is nonexistent or outdated, and the code signing procedures are complex and mundane. Moreover, the iOS and Android app signing procedures are very different.
A unique and essential element to iOS app signing is “Provisioning Profiles.” These profiles contain app information and entitlements, which specify the system resources an app can use. A provisioning profile acts as a link between the device(s) on which an app will be tested, the developer account, the app, and the app container in the Apple App Store. The same provisioning profile must be used for both the initial signing and any re-signing.
Apple enforces code signing and they control the process. Moreover, Apple is the only certificate authority that can provide code signing certificates for an iOS app. While developers and IT operations sometimes view this as inflexible or inconvenient, it is advantageous for end users and the entire ecosystem. This rigidity means end users can have high confidence that mobile apps that are to be installed on an iOS device are safe and malware-free, as they are vetted, reliable, and secure.
Given the importance mobile apps play in both the enterprise and consumer markets today, security is of utmost importance, and Apple’s approach reinforces this point. It is beneficial to companies to have a thoroughly vetted app that has been through extended validation. Without that, there is a higher likelihood that end users will call support services.
There are several ways developers can deploy apps to Android devices that do not require them to be signing code. Apps can be ‘sideloaded’ by physically connecting the device to a computer with a USB cable.
It is important to note that one of the biggest complaints about Android is how easy it is for a third-party, sideloaded app to cause problems on an end user's mobile device. Issues include the risk of creating app and OS instability, security warnings, and enabling malware to install itself.
If your mobile app portfolio grows to ten, twenty, or more apps, each of which comes from a different vendor, things get really complicated and challenging for signing code. But it doesn’t have to be this way. A secure app delivery platform for mobile that offers a code signing service can perform code signing as part of a deployment workflow, which ensures rigor over the entire process. With a code signing service, app signing can happen automatically as part of the deployment flow but it doesn’t always have to be so. For example, some companies have a separate team dedicated to perform app signing because the company wants to restrict who has access to the code signing certificates. In such a situation, the code signing service could be configured to provide a notification when the app is ready to be signed. Once the app signing service generates a notification, the app signing team can spring into action to complete the signing.
With all this in mind, here are the key activities that IT operations teams should pay attention to when approaching the app signing process and using any app signing service.
IT operations needs to obtain the proper distribution code signing certificates, typically from the development team. If IT operations cannot do the signing, they need to engage the signing team for re-signing. Within a large organization, there is typically a separate team for this function. There may be multiple code signing certificates, which this team will likely keep in a central key vault that only members of the signing team can access.
This can be particularly challenging with third-party apps, as IT operations has to coordinate with the third party to get the provisioning profile and make sure the profile's entitlements are correct before using an app signing service. The last thing anyone wants to see when trying to rapidly deploy a mobile app is spurious security warnings.
An app may need to be re-deployed, and therefore re-signed, multiple times a year by IT operations for reasons previously discussed. If anything has changed, such as a new app version that needs updating with a different provisioning profile, IT operations will run into issues when using an app signing service. This is especially common when apps come from third parties.
Copyright © Blue Cedar. All Rights Reserved. | US and Non-European Privacy Policy | GDPR Privacy Policy | Various trademarks held by their respective owners.