{'fraction_non_alphanumeric': 0.027505203687184062, 'fraction_numerical': 0.007582515611061552, 'mean_word_length': 4.83644251626898, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 6, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Software Authority Transition through Multiple Distributors

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.


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 builtin store, most distributors allow users other options. For example, the Android system allows access to Google's builtin 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.

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.
Conventional markets, however, must address the following two issues: license management and software installation. For license management, users purchasing from a webmarket 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.
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.

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.
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.

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).
(i) 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.

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.
The Scientific World Journal

Market User Developer
Register app Register update Support

Application Management from Multiple OASs
Software piracy has long been a serious security problem. Many proposals [2][3][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].
Therefore, many researchers have focused on prevention mechanisms against such threats [6][7][8][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.

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.

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.

4
The Scientific World Journal 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.

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.

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 1 , OAS 1 stores the user's purchase record. At a later time, if a user loses contact with OAS 1 , he can obtain support from OAS 2 by providing this proof of purchase. We assume that a user is always registered with at least one service.

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

P1: Initial User Registration
Phase. The user registration process is initiated when a user first registers with a specific store. Let a user, , register with store OAS 1 .
When requests their registration to OAS 1 , OAS 1 establishes a secure channel with . 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.
The Registration phase, P1 in Figure 7, registers to OAS 1 as shown in Figure 9. INFO U denotes the user purchase record stored by the OAS. When a user requests support from OAS 1 , the store verifies INFO U . INFO U includes the elements in Table 1.
When and OAS 1 establish a secure channel, selects and sends PWD to OAS 1 . OAS 1 gathers INFO U and generates cert U as follows: The Scientific World Journal 5  Figure 7, is invoked when contacts a new OAS, one from whom he did not purchase the application. We consider the case where requests support from OAS 2 . We assume that registers himself with OAS 2 , using the user registration phase, or temporarily contacts OAS 2 and then requests support for an application already purchased from OAS 1 .

Step 1: Check User's Registration Information.
To verify 's purchase record, OAS 2 checks 's registration information Addr U , as shown in Figure 8. Through a secure channel, requests the purchase authentication from OAS 1 and sends INFO U with pw U , cert U , TS U , and PR U to OAS 2 . OAS 2 then verifies cert U with OAS 1 's public key pk 1 . After verifying 's registration information, OAS 2 generates U with pw U and . OAS 2 then decrypts 's purchase record, PR U , with 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: temporarily uses a roaming service and permanently changes his OAS.