Software Authority Transition through Multiple Distributors

Abstract

The rapid growth in the use of smartphones and tablets has changed the software distribution ecosystem. The trend today is to purchase software through application stores rather than from traditional offline markets. Smartphone and tablet users can install applications easily by purchasing from the online store deployed in their device. Several systems, such as Android or PC-based OS units, allow users to install software from multiple sources. Such openness, however, can promote serious threats, including malware and illegal usage. In order to prevent such threats, several stores use online authentication techniques. These methods can, however, also present a problem whereby even licensed users cannot use their purchased application. In this paper, we discuss these issues and provide an authentication method that will make purchased applications available to the registered user at all times.

1. Introduction

In recent years, software distribution models have changed rapidly. Apple's iOS Appstore and iTunes made a significant change to the ecosystem of software and content distribution.

The convenience of these systems inspired other competitors and solutions. For mobile devices, for example, Google launched Google Play for their Android OS, and Amazon have developed their own Amazon Appstore. The success of these endeavors has influenced the PC-based OS software ecosystem. Microsoft has recently released Windows Store for Windows 8, and Apple has released Mac Appstore.

Whereas Apple's iOS only allows access to their built-in store, most distributors allow users other options. For example, the Android system allows access to Google's built-in store service as well as other mobile carriers' store services, even including those manually installed by the user. While users can purchase apps from the Windows and Mac appstores, they can also purchase them from other distributors or developers as well.

Although such market services provide significant convenience to users, they have introduced several issues. With the traditional software purchase environment, users could obtain product support regardless of where they purchased their applications. Users who purchase an application from a specific online appstore, however, cannot get support if they cancel or lose their connection to the store. Moreover, if an app requires an online authentication process to verify a valid license, the user will not even be able to launch the app.

In this paper, we discuss the software authorization issue and propose an extended “purchase authentication service” (PAS) model [1] that ensures users are authorized to access applications even if they change their status. Our extended PAS avoids the use of an independent system, which can cause overheads. We demonstrate two scenarios: (1) users are using a roaming service and (2) users permanently change their contact details.

We present an overview of the online application store model in Section 2. In Section 3, we discuss problems with application authorization. We then propose, in Section 4, an authentication protocol that allows a user to obtain authorization from multiple vendors. We then analyze the security of the model in Section 5 and conclude this paper in Section 6.

2. Online Application Store

Commercial consumer software was traditionally distributed as a package through offline markets. Users purchased an application from either (a) individual markets or (b) developers directly, as shown in Figure 1. When digital download services were introduced, users could still purchase from either source and receive support for that application by directly contacting the developer.

Figure 1.

Traditional distribution—(a) individual markets; (b) direct from developers.

Conventional markets, however, must address the following two issues: license management and software installation. For license management, users purchasing from a web-market could download the application directly from the specific website. For authorization, users received license codes through emails or receipts. Users had to keep or request new license codes from distributors when they were required to reinstall the app.

The mobile handset market, in addition to the PC market, also provided digital download services. For example, legacy mobile devices, such as those based on Palm OS and Windows CE, widely used until the late 2000s, enabled users to install any application they chose to their devices.

The installation process, however, was not convenient. Figure 2 shows an example of installing an application on a Palm OS-based device. To install an application, users had to manage a desktop application that synchronized with the mobile device.

Figure 2.

Application management in Palm OS. Legacy devices needed to connect to a PC to install mobile applications.

Although later Wi-Fi-enabled devices could download and install applications without desktop tools, the purchase and authorization process remained the same as shown in Figure 1. Users still managed their license codes themselves.

2.1. Online Application Stores

Online application stores (OASs) provide users with easier license and application code management. When a user purchases an app from an OAS, it requires only one click to install, reinstall, or update the app. In fact, the market share of Palm OS, Windows CE, and even Symbian OS quickly decreased once Apple launched the Appstore for iPhone. OASs are not only used with mobile devices. PC environments, including Windows and Mac OS X, and software distributors such as Amazon are rapidly deploying market services, as shown in Figure 3.

Figure 3.

(a) Windows marketplace (b) Mac Appstore.

Multiple OASs are often preinstalled or installed by users on their devices and systems. By connecting to an OAS, a user can easily purchase applications. When a user needs support, they can easily get updates from their application provider, as shown in Figure 4.

Figure 4.

Online application distribution.

2.2. Types of OAS User Registration

We separate OASs into the three groups discussed in [1]: OAS from OS holder (Type 1), OAS from Content distributor (Type 2), and OAS from mobile carriers (Type 3).

1. Type 1: the store application is preinstalled on the device. Users register their accounts with the service. To purchase applications, users must also register their billing information. Depending on the billing information or location information, the store can provide localized services. Microsoft's Windows Store, Apple's Appstore, the Ubuntu Software Center, and Google Play are examples.

2. Type 2: users manually install the store application on their device. Users register their accounts. To purchase applications, users must also register their billing information. Stores authenticate users with the billing information. Amazon Appstore and Steam Online are examples.

3. Type 3: mobile carriers/manufacturers preinstall their own OASs on the device. Mobile users are already registered through their carrier subscription information. The store verifies the information from the USIM in the device. Only subscribed devices can use the service. Users must be connected to the cellular network.

3. Application Management from Multiple OASs

In this section, we discuss issues with application management from multiple OASs and extend the PAS introduced in [1] to overcome such issues.

3.1. Application Management from Multiple OASs

3.1.1. Software License Check Problem

Software piracy has long been a serious security problem. Many proposals [2–4] have attempted to prevent this problem by the use of a software license confirmation. They focus on the verification of the validity of the software license from the original source.

For example, the Android system enables anyone to develop and distribute Android software. It uses the Android application package file (APK) format to distribute and install applications and middleware to the device. Although the Android system initially demands that all applications be signed by the application developer to ensure the trust of the applications, installing unauthorized applications manually is also allowed, as shown in Figure 5. This openness permits the illegal distribution of cracked applications and malware (Graham Cluley, “Android malware poses as Angry Birds Space game,” NakedSecurity, SophosLab April 12, 2012) to the Android system [5].

Figure 5.

Android OS allows unauthorized applications.

Therefore, many researchers have focused on prevention mechanisms against such threats [6–9], including online authentication. Such authentication systems, however, can decrease the availability of applications.

While many vendors do deploy online authentication systems, Type 3 distributors generally use an authentication process via a wireless network. For example, Korean local distributors, including SKT T-store and KT Olleh market, commonly utilize users' subscribed information in the USIM over the cellular network. When a user launches an application, they must be connected to the network. Those who are not connected to the network via a cellular connection fail to be authenticated.

3.1.2. Software Support without Original OAS

In the traditional application distribution environment shown in Figure 1, stores only provide applications to users. Users then contact the developers directly for support. Although this is not a very convenient process, once a user has purchased an application, they can obtain continued support from the developer.

In contrast, in the current distribution process shown in Figure 4, OASs not only sell applications but also provide support to users. Although such a mechanism brings huge convenience to users, they must maintain their connection to the store to receive this support. A user who cannot contact the store will fail to get further support and must purchase the same application again, from a different store that he can contact. This generally occurs for Types 2 and 3 cases, where the OAS only provides service for the localized domain.

3.1.3. OAS Management Problem

OAS users can purchase software from multiple OASs, as shown in Section 2.2. This can cause problems with verifying the license. Although allowing multiple OASs in a device allows users to choose their preferred service, any OAS that a user contacts can manage the software. Whereas legacy distribution systems allow users to get software support, regardless of where the application was purchased, OAS users can only get support from the OAS from whom they made their purchase.

Therefore, OAS users who purchase apps from multiple OASs must manage multiple OAS systems in the device, as shown in Figure 6. This increases the management overhead, especially to mobile device users.

Figure 6.

An example of various OASs in one mobile device: SKT T-store (Type 3), Google Play store (Type 1), and Amazon Appstore (Type 2).

3.2. PAS Model

In order to resolve the issues discussed above, we propose a PAS model. This enables users who have already purchased applications to receive support when they change their status or cannot reach the original OAS, temporarily or permanently [1]. We define the PAS as a trusted entity that stores users' purchase records. We have limited the functionality of the PAS model to the mobile environment.

4. Improved PAS Model

Maintaining an additional trusted entity for the PAS could increase the management overhead. In this paper, therefore, we extend the model by adding a PKI feature and modify the PAS as a part of this service. This does not require an additional entity, and hence there are no additional management issues. When a user purchases an application from OAS₁, OAS₁ stores the user's purchase record. At a later time, if a user loses contact with OAS₁, he can obtain support from OAS₂ by providing this proof of purchase. We assume that a user is always registered with at least one service.

4.1. Improved System Model

We assume the following system model, illustrated in Figure 7. A developer provides applications to the OASs. A user, U, purchases applications from the OASs. The OASs share their public keys, pk_j, 0 ≤ j ≤ n, where n is the ID of the OAS. Stores (OAS₁ and OAS₂) have a secure association. OASs also share the seed secret, s. Developers always register (1) and update (2) their applications. U must first register himself to an OAS, say, OAS₁. (3) After successful registration, U may purchase multiple applications from OAS₁. (4) OAS₁ stores U's information using the PAS. When U has a status change, he may request to update his registration to a newly connected store, OAS₂ (5). OAS₂ provides services after validating U (6).

Figure 7.

System model.

4.2. P1: Initial User Registration Phase

The user registration process is initiated when a user first registers with a specific store. Let a user, U, register with store OAS₁.

When U requests their registration to OAS₁, OAS₁ establishes a secure channel with U. We assume that email is used to establish the secure channel, as is used by many Internet services. Figure 8 shows an example of this process.

Figure 8.

Checking UAddr by email verification.

The Registration phase, P1 in Figure 7, registers U to OAS₁ as shown in Figure 9. INFO_U denotes the user purchase record stored by the OAS. When a user requests support from OAS₁, the store verifies INFO_U. INFO_U includes the elements in Table 1.

Figure 9.

P1: Registration phase.

Table 1.

INFO_U elements.

Element	Description
AddrU P	User's primary contact information (e.g., email address)
AddrU S	User's supplementary information (e.g., phone number; optional)
PNU	Device information (optional)
CNU	Country code (optional)
CRU	Carrier code (Type 3)
TS	Timestamp
pwU	Passcode for the registration
PRU	Purchase record of U

When U and OAS₁ establish a secure channel, U selects and sends PWD to OAS₁. OAS₁ gathers INFO_U and generates cert_U as follows:

$$\begin{array}{c}{\text{cert}}_{\mathcal{U}}={\mathrm{sign}}_{s{k}_{O_{\mathrm{1}}}}\{h\left({\text{Addr}}_{\mathcal{U}}^P\right)||h\left({\text{pw}}_{\mathcal{U}}\right)||\cdots \left(\text{opt}\right)\\ \hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\cdots ||h\left(\text{TS}\right)||h\left({\text{PR}}_{\mathcal{U}}\right)\},\end{array}$$ (1)

where sk _O1 is a private key of OAS₁ and sign⁡_k{m} denotes a signature of m signed by k. PR_U = enc_kU{App_i}, where i is the purchased app ID and k _U = f(pw_U||s), where f(m) is a key generation function with input m and s is the seed secret of the OASs. opt denotes optional information for deployment.

OAS₁ then sends TS, PR_U, and cert_U to U. U stores cert_U, PR_U, and TS.

4.3. P2: Purchase Phase

The purchase phase, P2 in Figure 7, is invoked when U purchases applications from OAS₁.

When U purchases App_i from OAS₁, OAS₁ updates PR_U. In the first step, OAS₁ decrypts PR_U with k _U and adds APP_i to the application list. If s is updated to s ^new, OAS₁ generates a new k _U ^new = f(pw_U | |s ^new). Then, PR_U ^new is generated by encrypting the updated application list using k _U ^new.

Finally, OAS₁ sends PR_U ^new to U, where it is also stored.

4.4. P3: Purchase Authentication Phase

The purchase authentication phase, P3 in Figure 7, is invoked when U contacts a new OAS, one from whom he did not purchase the application. We consider the case where U requests support from OAS₂. We assume that U registers himself with OAS₂, using the user registration phase, or temporarily contacts OAS₂ and then requests support for an application already purchased from OAS₁.

4.4.1. Step  1: Check User's Registration Information

To verify U's purchase record, OAS₂ checks U's registration information Addr_U, as shown in Figure 8. Through a secure channel, U requests the purchase authentication from OAS₁ and sends INFO_U with pw_U, cert_U, TS_U, and PR_U to OAS₂. OAS₂ then verifies cert_U with OAS₁'s public key pk_O1. After verifying U's registration information, OAS₂ generates k _U with pw_U and s. OAS₂ then decrypts U's purchase record, PR_U, with k _U.

4.4.2. Step  2: User Authorization

The processes are slightly different depending on the user's status. In this paper, we show two cases: U temporarily uses a roaming service and U permanently changes his OAS.

Case A: U Temporarily Uses a Roaming Service. When U connects to OAS₂ as a roaming service, OAS₂ grants temporary authorization to U. U still has his original PR_U, INFO_U, and Cert_U, and OAS₂ does not send a new certificate. OAS₂ has access to the billing information of U and can request payment. The authorization remains valid for a specific time period; for example, OAS₂ can authorize U for one day.

Case B: U Permanently Changes His OAS. When U permanently changes from OAS₁ to OAS₂, Cert_U from OAS₁ is revoked and OAS₂ issues a new Cert_U ^new to U. INFO_U is updated. For example, U may have a new Addr_U ^S. If the user keeps his old email, Addr_U ^P does not change. If the user connects using the same device, PN_U remains unchanged. TS_U is updated. U receives INFO_U ^new, Cert_U and stores them with PR_U. OAS₂ also stores the information. By this process, OAS₂ can bill U.

5. Security Analysis

In this section, we show that the security of the design satisfies standard security requirements and also show that the design is secure against possible attack. We assume OAS_i, where i is the ID of the OAS, can be trusted. Performance is not an issue in this paper and depends upon the actual deployment case.

5.1. Security Requirements

The following are the security requirements for the PAS model.

1. Nonrepudiation: the user should not be able to claim that his records are invalid.

2. Authentication: the distributor must be able to validate the user's request.

3. Privacy: the distributor can only know the user's information after the user is approved.

The handling of malicious applications in the store is not the focus of this paper.

5.2. Nonrepudiation

pw_U is chosen by U, and U does not know the k _U generated from pw_U. Since OAS₂ can request information about PR_U only when U requests a service, repudiation from U can be prevented.

5.3. Authentication

Cert_U enables OAS_i to check the validity of U. Since only a valid OAS_i can generate a Cert_U, using the private key sk _Oi, a malicious user or other attacker cannot forge or abuse it.

5.4. Privacy

Without pw_U, OAS_i cannot access the application list in PR_U. OAS_i can only generate the k _U that decrypts PR_U to see the application list when U sends pw_U.

U can replace pw_U at any time. Although a specific OAS_i can see the application list if a user chooses to use a temporary roaming service, it will not be aware of any future changes to pw_U.

Only hashed user information from Table 1 is stored in Cert_U. Thus, an unapproved OAS_i cannot know the information before U provides them with access.

5.5. Security against Possible Attack Scenarios

We assume that a malicious user Eve, E, could try to obtain support from a market without any purchase record. E could try the following scenarios.

5.5.1. Fraudulent User Tries to Get Authorization Illegally

E impersonates U. In this case, where the attacker impersonates a legal user, E would require INFO_U, including Addr_U, to impersonate U in OAS₁ or OAS₂.

E would not, however, be able to enter Addr_U during the PAS registration phase described in Section 4.4.1. Securing U's email account is not the focus of this paper.

Even when E compromises U's device and extracts INFO_U and Cert_U, E still does not know the password pw_U. Deploying the PAS model, OAS_i can limit the number of password attempts. For example, if several invalid password entries are attempted, OAS_i can temporarily place U's account on hold. In such a case, U would have to contact the service by phone or physical mail. We do not show the details of this process in this paper.

5.5.2. Forged Purchase Record

The malicious user E could forge his own purchase record PR_E. In this case, E would have to be able to modify PR_E in the PAS. For this to succeed, E would have to know s in order to generate k _E and then generate Cert_E. This is impossible without knowing sk _OASi.

6. Conclusion

With OASs becoming the main channel of software distribution, software license authentication issues present a potential problem when using multiple OASs. We have discussed possible issues from using multiple OASs and proposed an improved PAS model that reduces management overheads without any additional entity, while still allowing users to obtain support from multiple OASs. We refined our model to support a temporary roaming situation, as well as a permanent OAS change. We described the security of the proposed model.

Our design shows not only the technical availability of ongoing benefits to users, but also a possible business model for OASs.

Conflict of Interests

The authors declare that there is no conflict of interests regarding the publication of this paper.