App code signing process in iOS and iPadOS
In iOS and iPadOS, Apple offers app security through such things as mandatory code signing, strict developer sign-in, more.
Mandatory code signing
After the iOS or iPadOS kernel has started, it controls which user processes and apps can be run. To help ensure that all apps come from a known and approved source and haven’t been tampered with, iOS and iPadOS require that all executable code be signed using an Apple-issued certificate. Apps provided with the device, like Mail and Safari, are signed by Apple. Third-party apps must also be validated and signed using an Apple-issued certificate. Mandatory code signing extends the concept of chain of trust from the operating system to apps and helps prevent third-party apps from loading unsigned code resources or using self-modifying code.
How developers sign their apps
Developers can sign their apps through certificate validation (through the Apple Developer Program). They can also embed frameworks inside their apps and have that code validated with an Apple-issued certificate (through a team identifier string).
Certificate validation: To develop and install apps in iOS or iPadOS devices, developers must register with Apple and join the Apple Developer Program. The real-world identity of each developer, whether an individual or a business, is verified by Apple before their certificate is issued. This certificate allows developers to sign apps and submit them to the App Store for distribution. As a result, all apps in the App Store have been submitted by an identifiable person or organization, serving as a deterrent to the creation of malicious apps. They have also been reviewed by Apple to help ensure they generally operate as described and don’t contain obvious bugs or other notable problems. In addition to the technology already discussed, this curation process gives users confidence in the quality of the apps they buy.
Code signature validation: iOS and iPadOS allow developers to embed frameworks inside of their apps, which can be used by the app itself or by extensions embedded within the app. To protect the system and other apps from loading third-party code inside of their address space, the system performs a code signature validation of all the dynamic libraries that a process links against at launch time. This verification is accomplished through the team identifier (Team ID), which is extracted from an Apple-issued certificate. A team identifier is a 10-character alphanumeric string—for example, 1A2B3C4D5F. A program may link against any platform library that ships with the system or any library with the same team identifier in its code signature as the main executable. Since the executables shipping as part of the system don’t have a team identifier, they can only link against libraries that ship with the system itself.
Verifying proprietary in-house apps
Eligible businesses also have the ability to write proprietary in-house apps for use within their organization and to distribute them to their employees. Businesses and organizations can apply to the Apple Developer Enterprise Program (ADEP). For more information and to review eligibility requirements, see the Apple Developer Enterprise Program website. After an organization becomes a member of ADEP, it can register to obtain a provisioning profile that permits proprietary in-house apps to run on devices it authorizes.
Users must have the provisioning profile installed to run these apps. This helps ensure that only the organization’s intended users are able to load the apps onto their iOS and iPadOS devices. Apps installed through mobile device management (MDM) are implicitly trusted because the relationship between the organization and the device is already established. Otherwise, users have to approve the app’s provisioning profile in Settings. Organizations can also restrict users from approving apps from unknown developers. On first launch of any proprietary in-house app, the device must receive positive confirmation from Apple that the app is allowed to run.