Progress will discontinue Telerik Platform on May 10th, 2018. Learn more

Code Signing Glossary

General Concepts

Why do Apple and Google require code signing?

Code signing verifies the code author identity and ensures that the code has not been tampered with after it was code signed. Every change after the application has been code signed, renders the code signature invalid and iOS and Android will not launch the modified application. Apple also uses code signing to limit the distribution of iOS applications outside the App Store.

Back to Glossary

How are applications code signed?

Asymmetrical key cryptography and hashing algorithms are used to create the unique digital signature for your application. The digital signature is used to sign the resources in an application package, including the binary file. For more information about digital signatures, see Digital Signatures on Wikipedia.

First, hashes are created for every resource in the application package with the help of a hash algorithm. When you add or remove a resource, the change is not reflected in the hash manifest. When you replace an existing resource, its hash is not preserved. The signature manifest also has its own hash to prevent unauthorized changes.

Next, the hashes are encrypted with a private key. After the encryption is complete, the digital signature for the app is created.

When the app is deployed on device, the device operating system uses the hash algorithm to compute hashes for the resources. The operating system uses the public key to decrypt the hashes in the hash manifest. Then, the operating system compares the hashes from the hash manifest with the ones that it computed earlier. If the hashes do not match, the operating system considers the digital signature invalid and does not launch the application.

The public key proves the origin of the app. The hashes matching verifies that the resources are authentic. The public key is distributed with the provisioning profile inside the package. For more information about public and private keys, see What are public and private keys.

See also: Apple guide to code signing on Mac. Code signing for iOS is identical.

Back to Glossary

What are public and private keys?

Public and private keys are used in asymmetrical key cryptography. Data is signed with a private key and the identity of the data author is verified with the public key.

For example: If Jane wants to receive secure data from John, he needs to send her his public key. John can encrypt and sign his data with his private key and send the data to Jane. To verify that the author of the data is John and decrypt the data, Jane will use the public key that John shared with her.

In application code signing, the private key is used to encrypt the hashes manifest. The operating system uses the public key to decrypt the manifest. The public key is stored in a certificate.

Back to Glossary

What are public key certificates?

According to Wikipedia:

In cryptography, a public key certificate (also known as a digital certificate or identity certificate) is an electronic document which uses a digital signature to bind a public key with an identity — information such as the name of a person or an organization, their address and so forth. The certificate can be used to verify that a public key belongs to an individual.

For more information about certificates, see Public key certificate on Wikipedia.

Back to Glossary

iOS-Specific Terms

Certificate

To code sign an iOS application, you need a public key certificate signed by Apple as the certificate authority. A public key certificate contains information about the developer identity and a public key to decrypt anything encrypted with the private key of the developer. To manage your certificates, go to the iOS Dev Center.

Your certificates are embedded inside a provisioning profile.

With a development certificate, you can code sign an application during development in order to run it on device. You cannot publish apps signed with a development certificate. You can assign a development certificate to a development provisioning profile only.

With a production certificate, you can code sign an application for publishing on App Store and for distribution to specific testing devices. You can assign a production certificate to a distribution provisioning profile only.

Back to Glossary

Certificate Signing Request

Before Apple provides you with a development or production certificate, you need to submit a certificate signing request as a CSR file. The certificate signing request contains the information that will be included in your certificate. After you upload your certificate signing request to the Apple website, Apple signs it with a private key. This binds the public key with the developer information that you provided in the certificate signing request. In result, you receive a certificate signed by Apple as a certificate authority. For more information about certificate authorities, see Certificate Authority on Wikipedia.

With AppBuilder, you do not need a macOS system to create a certificate signing request. The AppBuilder clients let you create a certificate signing request from the Options dialog.

Back to Glossary

UDID

The Unique Device Identifier (UDID) uniquely identifies an iOS device. You need to provide it when you register an iOS device to your Apple developer account. To manage your registered devices, go to the iOS Dev Center.

When you create a development provisioning profile or an Ad Hoc distribution provisioning profile, you need to associate the profile with iOS devices that are registered to your Apple developer account.

Back to Glossary

iOS App ID

Not to be confused with the Telerik Platform App ID which is the unique identifier for your app in the Telerik Platform. For more information about the Telerik Platform App ID, see App Settings.

The iOS App ID uniquely identifies an application with the Apple application services. The Apple application services include Push Notifications, In-App Purchase, Game Center and so on.

The iOS App ID consists of a prefix and a suffix. The prefix is an Apple generated seed (for example, ABCDE12345). The suffix is a user-defined bundle identifier, usually a reverse URL (for example, com.yourcompany.SuperSocial). The bundle identifier must consist of one or more alphanumeric strings, separated by a dot. The strings must be valid uniform type identifiers (UTIs), containing letters (A-Z, a-z), numbers (0-9), hyphens (-) or periods.

With the example prefix and suffix, the App ID is ABCDE12345.com.yourcompany.SuperSocial.

The App ID prefix is identical across all your applications in your Apple developer account.

An explicit App ID lets you incorporate Apple application services in your app and create a unique provisioning profile for your app. You cannot use an explicit App ID across multiple applications and provisioning profiles. To create an explicit App ID, you need to specify a unique bundle identifier.

A wildcard App ID lets you use a single App ID with a single provisioning profile across multiple apps but you cannot incorporate Push Notifications, In-App Purchase and Game Center in your apps.

Back to Glossary

Bundle Identifier

The bundle identifier is the App ID suffix and is used to uniquely identify an iOS application. The application identifier must consist of one or more alphanumeric strings, separated by a dot. The strings must be valid uniform type identifiers (UTIs), containing letters (A-Z, a-z), numbers (0-9), hyphens (-) or periods. Usually the bundle identifier is a user-defined reverse URL.

With a unique bundle identifier, presenting a complete reverse URL, you can create an explicit App ID.

With a wildcard bundle identifier, containing an asterisk (*) or consisting of a single asterisk (*), you can create a wildcard App ID.

After you define the bundle identifier for an App ID, you cannot modify the bundle identifier.

Back to Glossary

Provisioning Profile

The provisioning profile is stored as a mobileprovision file. This file contains information about the identity of the app author, the identity of the app and its distribution purpose. To manage your provisioning profiles, go to the iOS Dev Center.

For development purposes, you can use a development provisioning profile. It enables debugging on device for the application. With a development provisioning profile you cannot publish to the App Store and you can only run your application on a limited number of predefined devices. When you create a development provisioning profile, you need to select an iOS App ID, one or more development certificates and one or more iOS devices registered to your Apple developer account.

To publish an app to the App Store or to distribute it to a limited number of predefined devices for testing purposes, you can use a distribution provisioning profile. It disables debugging on device for your application.

To publish an app to the App Store, you need to use an App Store distribution provisioning profile. When you create this type of distribution provisioning profile, you need to select an iOS App ID and one or more production certificates.

You do not need to have an iOS device registered to your Apple developer account, to create an App Store distribution provisioning profile.

To distribute an app to a limited number of devices only, you can use an Ad Hoc distribution provisioning profile. The app will run only on devices listed in the provisioning profile. When you create this type of provisioning profile, you need to select an iOS App ID, one or more production certificates and one or more iOS devices registered to your Apple developer account.

Back to Glossary

IPA File

IPA stands for iPhone Application Archive. If you extract it as a ZIP file, inside the archive, you will find an .app folder which is the actual application.

Back to Glossary

Android-Specific Terms

Package Identifier

The package identifier uniquely identifies an Android application. The application identifier must be unique and might contain one or more strings, separated by a dot. Each string must start with a letter and might contain letters (A-Z, a-z), numbers (0-9) or underscores (_). The individual strings must not be Java keywords. Usually, the package identifier is a user-defined reverse URL. For more information about package identifiers, see Android Manifest. Each part of the package identifier should start with a letter.

See also: Bundle Identifier and Application Identifier

Back to Glossary

AppBuilder-Specific Terms

Application Identifier

Not to be confused with the Telerik Platform App ID which is the unique identifier for your app in the Telerik Platform. For more information about the Telerik Platform App ID, see App Settings.

The application identifier is used to uniquely identify your application. It is usually provided in the form of a reverse URL that might contain a wildcard. In AppBuilder, application identifier is a synonym for both bundle identifier and package identifier.

The application identifier uniquely identifies an app on both iOS, Windows Phone and Android devices and in their respective application stores.
The application identifier must consist of one or more alphanumeric strings, separated by a dot. The strings must be valid uniform type identifiers (UTIs), containing letters, numbers, hyphens, underscores or periods.

Back to Glossary

Cryptographic Identity

The cryptographic identity is a pair of matching public key certificate and private key. You can manage your cryptographic identities in the Options dialog.

Back to Glossary

Code Signing Identity

The code signing identity is the combination of a provisioning profile and a cryptographic identity. In the classic Windows desktop client and the extension for Visual Studio, you can set code signing identities for iOS and for Android for testing purposes, in the Properties dialog.

Back to Glossary

See Also

Start a free trial Request a demo
Contact us: +1-888-365-2779
sales@telerik.com
Copyright © 2016-2017, Progress Software Corporation and/or its subsidiaries or affiliates. All rights reserved.