Android Application signature and permissions enhance application security

Sandbox, process, and permission

In Linux, a user ID identifies a given user. on Android, a user ID identifies an application. The application is assigned a user ID during installation. The user ID remains unchanged during the lifetime of the application on the device. Permission is about allowing or restricting applications (rather than users) to access device resources.

Android uses the sandbox concept to implement separation and permissions between applications to allow or deny an application to access device resources, such as files and directories, networks, sensors, and APIs. Therefore, Android uses some Linux utilities (such as process-level security, application-related users, group IDs, and permissions) to implement the operations that an application can perform.

Two Android applications, each in their own basic sandbox or process

Android applications run on their own Linux processes and are assigned a unique user ID. By default, applications running in basic sandbox processes are not assigned permissions, thus preventing such applications from accessing systems or resources. However, Android applications can request permissions through the manifest file of the application.

Android applications allow other applications to access their resources by doing the following:

Declare appropriate manifest Permissions

The program runs in the same process as other trusted applications to share access to their data and code.

The latter is shown in figure 2.

Two Android applications run in the same process

Different applications can run in the same process. For this method, you must first sign these applications with the same private key, and then assign them the same Linux User ID using the manifest file, this is done by defining the manifest attribute android: sharedUserId with the same value/name.

Developer Cases

Figure 3 demonstrates a lot of security-related use cases that will be found during Android application development.

Figure 3. Security fields when compiling Android applications

An application or code signature is a process in which private, public key, and public key certificates are generated to sign and optimize the application.

Permission is a security mechanism of the Android platform to allow or restrict application access to restricted APIs and resources. By default, Android applications are not granted any permissions and are not allowed to access protected APIs or resources on devices, thus ensuring their security. The permission must be requested, and custom permissions are defined. Files and content providers can be protected. Check, execute, Grant, and revoke permissions at runtime.

Next, let's take a closer look at each security field.

All Android applications must be signed. An application or code signature is a process in which private keys are used to sign a given application so that:

Identify the author of the Code

Check if the application has changed

Build trust between applications

Based on this trust relationship, applications can securely share code and data.

Two applications signed with the same digital signature can grant permissions to each other to access the signature-based API. If they share the user ID, they can also run in the same process, this allows access to the code and data of the other party.

The application signature first generates a private, public key pair, and a public key certificate.

The debugging and release modes can be used to build Android applications:

Applications built using Android build tools (command line and Eclipse ADT) use an automatic signature for debugging private keys. These applications are called debug mode applications. The debug mode application is used for testing and cannot be released. Note: apps that are not signed or that use the debugged Private Key signature cannot be released through the Android Market.

When you are about to release your own application, you must build a release mode version, which means that the application is signed with a private key.

The code signature in Android is much simpler than other mobile platforms. On Android, certificates can be self-signed, which means no certificate authorization is required. This method simplifies the release process and related costs.

Next, we will introduce how to manually sign the Android Application from the command line and by using Eclipse ADT. This article does not introduce the third method, that is, Ant.

Manually create private, public key, and Public Key Certificates

Recall that the debug mode application uses the debug key/certificate to automatically sign the signature by the build tool. To sign a publishing mode application, you must first generate a private, public key pair, and Public Key Certificate. You can sign the application manually or by using Eclipse ADT. Both methods use the Java Developer Kit (JDK) keytool key and Certificate Management utility.

To manually generate private and public key information, you can use keytool from the command line, as shown in Listing 1.

Listing 1. Using keytool to generate private/public keys and certificates

 
 

  
  
keytool -genkey -v -alias -keystore 
  
  
 
  
  
-keyalg RSA -keysize 2048 -validity 
 
 

Note: Listing 1 assumes that the JDK has been installed on your computer and the JAVA_HOME path is correctly defined as pointing to your JDK directory (see references for download and setup information ).

In listing 1,-genkey represents a public and private key pair, and an individual element certificate chain signed by X.509 v1, which contains the generated public key. -V indicates the lengthy mode. -Alias is the alias used for keystore items. It stores the generated private keys and certificates. -Keystore indicates the name of the key warehouse used. -Keyalg is an algorithm used to generate a key pair. -Keysize indicates the size of the generated key. The default size is 1024, but the recommended size is 2048. -Validity is the number of valid days. A value greater than 1000 is recommended.

Note: After the key is generated, you must ensure the security of the key. Do not share the private key or specify the key in the command line or script. Note that keytool and jarsigner will prompt you to enter the password. For more information about this and other tips, see "Securing Your Private Key" on the Android Developers website (see the link in reference ).

Keytool prompts you to enter the Name, Name, company, city, state, and country to generate an X.500 Distinguished Name from this information (for more information, see references ), enter the password to protect the private key and the key warehouse itself.

For the validity period, make sure that you use a period that exceeds the expected life cycle of the application itself and related applications. If you publish an application on the Android Market, the validity period must be later than January 1, October 22, 2033. Otherwise, the application cannot be uploaded. In addition, having a long-lived certificate makes it easier to upgrade applications. Fortunately, the Android Market enforces a long-lived certificate to help you avoid such problems.

Manually sign the application

Next, use the jarsigner tool (which is part of JDK) to sign unsigned applications:

 
 

  
  
jarsigner -verbose -keystore 
 
 

In the above Code,-verbose indicates the lengthy mode, and-keystore indicates the name of the key warehouse used. The following is the application name (.apk), and the alias used for private key.

Jarsigner prompts you to enter the password when using the key warehouse and private key.

Applications can use different keys for multiple signatures. Applications signed with the same private key can establish a trust relationship and run in the same process, share code and data.

Optimize applications manually

The last step in the signing process is to optimize the application so that the data boundary is aligned with the memory at the beginning of the file, which helps improve runtime performance and memory utilization. To sign the application, you can use zipalign:

 
 

  
  
zipalign -v 4 your_project_name-unaligned.apk your_project_name.apk 
 
 

In the previous Code,-v indicates lengthy output. The number 4 indicates that the four-byte alignment is used (the four-byte alignment is always used ). The next parameter is to enter the name of the signed application (.apk), which must be signed with your private key. The last parameter is the output file name. If the existing application is overwritten, add a-f parameter.

Manually verify that the application has been signed

To verify that the application has been signed, use Jarsigner to pass the-verify flag this time:

 
 

  
  
jarsigner -verify -verbose -certs my_application.apk 
 
 

In the previous Code,-verify indicates the verification application;-verbose indicates the lengthy mode;-certs indicates the CN field for creating the key, the last parameter is the name of the Android application package to be verified.

NOTE: If CN reads "Android Debug", it means that the application is signed with a debugging key, which means it cannot be released. If you plan to release your application on Android Market, remember to use a private key.

I learned how to manually create private and public keys and sign and optimize applications. Next, learn how to use Eclipse ADT to automatically create private and public keys, and sign and optimize applications.

Use Eclipse ADT to create keys and certificates, and sign and optimize applications

To use Eclipse ADT to generate a key, you must export the application. There are two ways to export an application from Eclipse:

Export the unsigned version of the application that you must manually sign

Export the signed version of the application. All the steps are performed by the ADT.

Export unsigned applications

You can export the unsigned version of the application that you must manually sign. That is to say, You need to manually run keytool (as described earlier, to generate the key) and Jarsigner (to sign the application) and use zipalign to optimize the application, as described earlier.

To use ADT to Export the Unsigned version of the Application, right-click the project and choose Android Tools> Export Unsigned Application Package (see figure 4 ).

Figure 4. Export unsigned applications

After the selection, ADT prompts you to select a directory to export unsigned applications. Remember, once an application is exported, you must manually sign and optimize the application, as described earlier.

Export signed applications

With Eclipse ADT, you can export the signed version of the application. Using this method, ADT prompts you to enter the following content:

Information required to use an existing KeyStore or create a new protected KeyStore

Information required to create a protected private key

Information required to generate a Public Key Certificate

To Export Signed applications, right-click the project, but choose Android Tools> Export Signed Application Package this time, as shown in Figure 5.

Figure 5. Export signed applications

In this case, the Export Wizard command is executed, as shown in figure 6.

Figure 6. Export Wizard

In Figure 7, select an existing key warehouse (or create a new one) and certificate.

Figure 7. Export Wizard: Key warehouse Selection

In figure 8, enter information to create a private key and digital certificate.

Figure 8. Export Wizard: create a private key and a digital certificate

In Figure 9, enter the path and name of the target file and verify the validity period.

Figure 9. Enter the path and name of the target file

When the release mode is complete, you have a signed and optimized application in the release mode, and you can release it.

You can also use the Android Manifest tool to call the Export Wizard, as shown in figure 10.

Figure 10. Use the Android Manifest tool to call the Export Wizard

After the application is signed, the next step is to define the permissions required by the application in manifest. Next, we will describe this process.

Note: The Android Developer website has excellent documents about application signing. These documents will be updated when new versions of the Android platform are available.

Permission

Permission is a security mechanism of the Android platform. It is designed to allow or restrict application access to restricted APIs and resources. By default, Android applications are not granted permissions, which ensures their security by not allowing them to access protected APIs or resources on the device. Permissions are requested by the application through the manifest file during installation, and are granted or not granted by the user.

Android defines a long series of manifest permissions to protect all aspects of the system or other applications. To request permissions, you can declare an attribute in the manifest file:

Android: name specifies the permission name.

For a list of all Android-defined manifest permissions, see the Manifest. permisson page. Listing 2 is an example of a manifest file that requests Internet access and write to external storage:

Listing 2. Declaring (request) Permissions

 
 

  
  
android:versionCode="1" 
  
  
 
  
  
android:versionName="1.0" 
  
  
 
  
  
package="com.cenriqueortiz.tutorials.datastore" 
  
  
 
  
  
android:installLocation="auto"> 
  
  
 
  
  
: 
  
  
 
  
  
: 
  
  
 
  
  
: 
  
  
 
  
  
android:name="android.permission.INTERNET"/> 
  
  
 
  
  
android:name="android.permission.WRITE_EXTERNAL_STORAGE"/> 
 
 

Applications can define their own custom permissions to protect application resources. To access protected resources of an application, other applications must request appropriate permissions through their own manifest files. Listing 3 shows an example of how to define permissions.

Listing 3. Declaring custom Permissions

 
 

  
  
xmlns:android="http://schemas.android.com/apk/res/android" 
  
  
 
  
  
android:name="com.cenriqueortiz.android.ACCESS_FRIENDS_LIST" 
  
  
 
  
  
android:description="@string/permission_description" 
  
  
 
  
  
android:label="@string/permission_label" 
  
  
 
  
  
android:protectionLevel="normal" 
  
  
 
  
  
> 
 
 

In listing 3, a custom permission is defined by specifying the minimum attribute, namely name, description, label, and protectionLevel. You can also define other attributes, but this is not described here.

It is particularly interesting that the android: protectionLevel attribute represents the method the system should follow when granting (or not granting) a given permission to an application requesting permissions. Protection levels are common and dangerous. The former automatically grants permissions (although users can always review permissions before installation) and grant permissions based on signatures (that is, if the application requesting permissions is signed with the same certificate ); the latter indicates the permission to give access to private data, or has another potential negative impact. For more information about the manifest attribute, see the page (see references ).

Applications can restrict access to applications and their system components (such as Activity, Service, Content Provider, and Broadcast Explorer. This restriction is easily implemented by defining the android: permission attribute as in Listing 4. This level of protection allows applications to allow or restrict other applications to access system resources.

Listing 4. Define the permissions for an activity

 
 

  
  
android:name=".FriendsListActivity" 
  
  
 
  
  
android:label="Friends List"> 
  
  
 
  
  
android:permission="com.cenriqueortiz.android.ACCESS_FRIENDS_LIST" 
  
  
 
  
  
: 
  
  
 
  
  
: 
 
 

Content provider and File Permissions

The content provider exposes a public URI for uniquely identifying their data (see references ). To protect this content provider, the caller can set Intent. FLAG_GRANT_READ_URI_PERMISSION and Intent. FLAG_GRANT_WRITE_URI_PERMISSION at the beginning or when returning results from the activity to grant access to specific data Uris.

Application Files are protected by default. Files are protected based on user IDs, so they are accessible only to the owner application (this application has the same user ID ). As described above, applications that share the same user ID (and sign with the same digital certificate) run on the same process and thus share access to their applications.

Applications can allow other applications or processes to access their files. This can be done by specifying the appropriate MODE_WORLD_READABLE and MODE_WORLD_WRITEABLE operation modes (to allow read or write access to files) or MODE_PRIVATE (to open files in private mode. You can use the following methods to specify the operation mode when creating or opening a file:

 
 

  
  
getSharedPreferences(filename, operatingMode) 
  
  
 
  
  
openFileOutput(filename, operatingMode) 
  
  
 
  
  
openOrCreateDatabase(filename, operatingMode, SQLiteDatabase.CursorFactory) 
 
 

Runtime Permission API

Android provides various APIs to check, execute, Grant, and revoke permissions at runtime. These APIs are part of the android. content. Context class, which provides global information about the application environment. For example, if you want to handle permissions elegantly, you can determine whether your application has been granted Internet access permissions (see OK 5 ).

Listing 5. Check permissions when using the runtime Permission API

 
 

  
  
if (context.checkCallingOrSelfPermission(Manifest.permission.INTERNET) 
  
  
 
  
  
!= PackageManager.PERMISSION_GRANTED) { 
  
  
 
  
  
// The Application requires permission to access the 
  
  
 
  
  
// Internet"); 
  
  
 
  
  
} else { 
  
  
 
  
  
// OK to access the Internet 
  
  
 
  
  
} 
 
 

For details about other APIs that check, execute, Grant, and revoke permissions at runtime, refer to the context class.

Security on the Android platform, including sandbox, application signature, application permissions, and file and content provider permissions. After reading this introductory article, you will be able to use Eclipse to manually create digital certificates, request application permissions, and allow or deny application access to files and content providers. In addition, you have a brief understanding of the runtime APIs that allow you to check, execute, Grant, and revoke permissions during runtime.