Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 33.221  Word version:  18.0.0

Top   Top   Up   Prev   None
1…   4…   A… 
A Key pair storage  A.1 Introduction  A.2 Key pair storage use-cases  A.3 Threats associated with the key pair  A.4 Security risk analysis related to key pair storage  $ Change History 

 

A  Key pair storage  p. 18

A.1  Introduction  p. 18

The storage of the public/private key pair associated to the requested subscriber certificate is relevant to the procedure of issuing subscriber certificates.
The key pair storage can be performed in different ways. The nature of this storage may have impacts on the trust level associated to the subscriber certificates.
This annex provides a key pair storage security risk analysis in different scenarios.

A.2  Key pair storage use-cases  p. 18

There are different scenarios to store the public/private key pair associated to the requested subscriber certificate.

A.2.1  Key pair storage on the ME  p. 18

A possible place for the storage of the key pair is the Mobile Equipment.
There are two alternatives for the key pair storage on the ME: key pair storage on the MT or on the TE.

A.2.2  Key pair storage on the UICC  p. 18

Another solution for the storage of the key pair is the UICC.
For the following study we will consider only two key pair storage use-cases: on the ME or on the UICC.

A.3  Threats associated with the key pair  p. 18

A.3.1  Key pair generation  p. 18

The key pair generation is a very sensitive operation for the secrecy of the private key. The key pair generation has to be of good quality and the exchange, between the device where the key pair generation took place and the device where the key pair will be stored, has to be protected to avoid private key cloning/disclosure. UICC provides a greater level of protection, compared to ME, against unauthorized access to the private key itself.

A.3.2  Unauthorized usage of the private key  p. 18

There are two kinds of threats associated with unauthorized usage of the private key:
  1. An attacker getting hold of the private key; and
  2. An attacker using the private key of the victim without getting hold of that key.
With respect to threat 1, having the key in UICC offers better protection than having it in the ME. However, an attacker who can compromise the ME can possibly use the private key for unauthorized purposes even if it is in the UICC because the UICC does not have direct trusted path to the user.
Attacks due to threat 2 always require an interaction with the UE to gain access to the UICC. While with the threat 1, as soon as the key is retrieved, the associated attacks do not requires any interaction with the UE to use the retrieved private key.
Up

A.3.3  Portability  p. 19

If the key pair is stored on the Mobile Equipment there is a threat in case of a new UICC inserted in this ME. There will be on the ME personal and sensitive data that do not belong to the new user. Since access to private keys is protected by PINs or passwords, the new user cannot access the private key of the old user unless he knows the PIN or the password.
Also, an important aspect of enrolling subscriber certificates based on AKA is the use of short-lived certificates. With short-lived certificates, even if the new user can access the old user's private key, it could happen that he cannot masquerade as the old user in authorization transactions because he can no longer get subscriber certificates for the key pair on behalf of the old user if the subscriber certificate expired. Moreover, if the key pair in ME is short-lived, owner of the new UICC will not be able to use that key pair after the pair expires. But there is no assumption that the subscriber certificate/key pair expired when the new user gets access to the old user's private key. In general, short-lived keys - on UICC or on ME - are useful for identity and privacy protection. Frequent change of key pair prevents outsiders from linking together transactions made by same user.
Up

A.3.4  Environment  p. 19

The threats to the key pair depend on the environment, the place of the key pair storage.
All implementations on mobile terminal, PC, MAC or PDA leave potential risks such as the possibility to load Trojan horses, worms or virus. Software applications lack the protective mechanisms existing in smart card (tamper resistance, physical encapsulation of critical circuitry). Reverse engineering techniques, such as extracting program code and disassembly/debugging methods, are simplified greatly in a software environment, allowing a token's secret components such as cryptographic algorithms, private keys, and other assumed secure information to be recovered.
Currently, the Mobile Equipments do not have all the hardware and software countermeasures that are built into UICC to protect them against invasive and non-invasive attacks performed to retrieve secrets. But mechanisms like code signing are already being taken into use.
Up

A.3.5  Threat to the required properties for digital signatures  p. 19

To be valid, digital signatures require the following properties:
  • Authenticity: a valid signature implies that the signer deliberately signed the associated message;
  • Unforgeability: only the signer can give a valid signature for the associated message;
  • Non-re-usability: the signature of a document can not be used on another document;
  • Non-repudiation: the signer can not deny having signed a document that has valid signature;
  • Integrity: ensure the contents have not been modified.
Those properties involve the secrecy of the keying material, having a trusted input/output path to the user, and the use of strong and secure cryptographic mechanisms.
So, the trust in the digital signatures depends on the storage of the key pair and the related cryptographic computations and the security of communication between the user and the module performing private key operations. The impacts of the key pair storage are studied in the following clause A.4.
Up

A.4  Security risk analysis related to key pair storage  p. 20

There are many different subscriber use-cases describing the range of applications or services utilizing subscriber certificates. But, the level of trust associated to the proposed services depends on the key pair storage. This will be presented in the following security risk analysis.

A.4.1  Subscriber certificate use-cases  p. 20

The use-cases for subscriber certificates can be divided into 2 main categories:

A.4.1.1  Secure services  p. 20

Those services provide convenient way of authenticating cellular subscribers to services. These services can be provided by cellular operators, corporations, or 3rd party content providers. Secure services may also support billing.
The different subscriber use-cases could be:
  • person-to-person authentication: per-to-per authentication;
  • corporate services: authentication to corporate intranet applications;
  • person-to-content:
    • access to Presence services;
    • self-service management;
    • access to operator's Web services;
    • access to 3rd party content services;
    • enhanced LCS privacy;
    • notifications through cellular network;
    • MBMS security;
    • support of Liberty Alliance use cases;
  • small to medium payment through cellular operator.
Up

A.4.1.2  Secure connectivity  p. 20

This service utilizes cellular infrastructure and existing operators customer relationships to authenticate users:
  • alternative access authentication:
    • corporate WLAN access authentication;
    • broadband access, e.g. DSL or cable access;
  • service authentication: e.g. VPN authentication.

A.4.2  Security risk analysis in some scenarios  p. 20

All subscriber use-cases do not require the same level of security for the key pair storage since they propose services that have different features in terms of:
  • added value: high or low valued services;
  • involved partners and trust relationships: there is agreement between different cellular network operators or between cellular network operator and service provider or 3rd party content provider;
  • type of required certificates (short-lived or long-term certificates).
This section presents some scenarios where the nature of the key pair storage has security impacts on the service.
Up

A.4.2.1  Scenarios involving subscriber's personal data  p. 21

An example of scenario involving subscriber's data could be the self-service management.
A.4.2.1.1  Self-service management  p. 21
This scenario allows user to authenticate to a Web portal, run by operator, to achieve secure access for self-provisioning. Secure end-to-end (TLS) tunnel from the terminal to the Web portal can be established (subscriber's private key and the certificate are used in standard fashion, i.e. no changes needed in TLS components). The user can have either mobile or fixed network access (e.g. GPRS, WLAN, or xDSL). The main use cases are billing information queries and modifying one's subscription profile.
User experience:
The authorization may be based directly on subscriber certificates, or on a combination of authentication with subscriber certificate and access control list in the Web portal. In the first case the self-management server:
  • receives an assertion signed by the data owner, which contains a public key and set of access rights;
  • verifies that the sender of the assertion holds the matching private key; and
  • allows the secure access (e.g. TLS connection) only if the verification succeeds.
Up
A.4.2.1.2  Security Risk Analysis in this scenario  p. 21
The security risk analysis is performed according to the unauthorized usage threats identified in clause A.3.2.
Unauthorized usage by using the private key of the victim without retrieving the private key:
Potential attack:
so, an attacker could get usage of the subscriber private key to authenticate to the Web portal and access for self-provisioning. The attacker could for example modify the subscription profile of the subscriber.
Feasibility:
the attacker requires an interaction with the UE to gain access to the UICC.
the attack applies in case of:
  • key pair storage on the ME;
  • key pair storage on the UICC.
Unauthorized usage by getting hold of the private key:
Potential attack:
so, an attacker could retrieve the subscriber private key to authenticate to the Web portal and access for self-provisioning. The attacker could for example modify the subscription profile of the subscriber.
Feasibility:
once the key retrieved, the attacker does not require any interaction with the UE equipment to gain access to the UICC.
the attack applies in case of:
  • key pair storage on the ME
This attack is based on the key retrieval. So, as the UICC is tamper resistant device so the attack does not apply to UICC.
Consequences of these attacks:
the self-service management is low added value and the consequences of the key pair storage on the UE are limited.
Up

A.4.2.2  Scenarios involving payment and agreement between operator and service provider  p. 22

Some scenarios deal with payment and agreement between cellular network operator and service provider, 3rd party.
A.4.2.2.1  Notifications through cellular network scenario  p. 22
The subscriber authorizes the operation of sending notifications by service provider through the cellular network. The service provider does not need to know subscriber's identity. If there is no identity information in the certificate, then the subscriber may remain anonymous towards the service provider. However, subscriber may pay for the notification through his phone bill. Subscriber authorizes such payment and the charging is triggered when the service provider sends a notification.
User experience:
During a transaction UE sends to the service provider an assertion, i.e. signed authorization, to send a notification message to that UE through the cellular network, and subscriber certificate or subscriber certificate URL. The service provider verifies the authorization text and UE's signature with the aid of subscriber certificate. If the signature and the authorization text are correct, then the service provider will send a positive acknowledgement to the UE.
At a later time, for example when a certain sport's event takes place, the service provider creates a notification and submits it to the operator together with the signed UE's authorization and subscriber's certificate. The operator verifies the signed authorization. If the verification succeeds the operator will forward the notification text to the subscriber in an SMS or MMS message.
Up
A.4.2.2.2  Small to medium payment through cellular operator scenario  p. 22
The subscriber authorizes payment for a service through his phone bill (or with separate bill). Note that the provider of the service does not need to know subscriber's identity. If there is no information in the certificate, then the subscriber may remain anonymous towards the service provider. The service may be e.g. non-cellular access in a environment where the operator's traditional billing mechanisms are not directly applicable, e.g. non-cellular access is provided by 3rd party.
During a payment transaction the UE sends to the service provider a signed invoice and subscriber certificate (or subscriber certificate URL). The service provider verifies the UE's signature with the aid of subscriber certificate. If the signature and the invoice are correct, then the service provider will grant UE access to, or deliver the requested service.
In the settlement phase the service provider forwards the signed invoice to the operator for verification. If the verification is successful then the operator will reimburse service provider and charge the subscriber the price of the service through his phone bill (or with separate bill).
Prerequisite:
the service provider has a business relationship with operator that issued subscriber's certificate and it knows operator's signature verification key.
if the service provider (e.g. visited access network provider abroad) does not have a direct relationship with the subscriber's home network, the certificate should come from the visited network. The independent access network provider trusts the visited operator as well as the subscriber authentication and certificate from that operator.
User experience:
the subscriber trusts the billing from the home operator and payment is convenient. During the service usage he will have to type in the payment PIN for configured amounts. The terminal may automatically sign very small amounts. In this case only larger amounts and cumulative sum above a threshold trigger the PIN query.
Up
A.4.2.2.3  Security Risk Analysis in these scenarios  p. 23
These secure services deal with payment and an agreement between a cellular network operator and a service provider. The nature of the key pair storage has consequences. The security risk analysis is performed according to the unauthorized usage threats identified in clause A.3.2.
Unauthorized usage by using the private key of the victim without retrieving the private key:
Potential attacks:
if the ME is not sufficiently secure, the attacker may have a program that shows the user a certain message ("payment of €1") but ask the UICC to sign a different message ("payment of €100"). Also if the attacker's program discovers the PIN, it can command the UICC to generate signatures even without the user being aware of it.
Feasibility:
the attacker requires an interaction with the UE to gain access to the UICC.
these attacks apply in case of:
  • key pair storage on the ME;
  • key pair storage on the UICC.
Unauthorized usage by getting hold of the private key:
Potential attacks:
if an attacker manages to discover the subscriber's private key then an attack could consists in sending signed authorizations to the service provider, then the subscriber would have to pay for services he did not ask for.
Feasibility:
once the key retrieved, the attacker does not require any interaction with the UE equipment to gain access to the UICC.
The attack applies in case of:
  • key pair storage on the ME.
This attack is based on the key retrieval. So, as the UICC is tamper resistant device so the attack does not apply to UICC.
Consequences of these attacks:
  • forgeability: the subscriber could pay for services he did not ask for;
  • repudiation: The cellular network operator and the service provider are not paid for the service they provided.
If there is any way to attack the system a signer can repudiate the performed signatures arguing that the system is not secure. So, if it is possible to use the subscriber's private key without his deliberate consent, then the subscriber can repudiate the signatures sent for authorization, and not pay the associated phone bill. So,:
  • the operator and the service provider could not be paid for the proposed service;
  • the trust relationship between the operator and the service provider can be destroyed. The service provider has no guaranty of security; he would no longer trust the subscriber certificates issued by the cellular network operator and the associated signatures;
if there is any problem due to some unauthorized usages of the subscriber private key then the trust in 3G PKI may be lost;
high valued services involving payment and relationship with service provider or 3rd party content provider often require the use of long-term certificates. The issuance of long-term certificates requires more security constraints than the issuance of short-lived certificates. So, according to the unauthorized usage threats present on the UE, the security level may not satisfy the security requirements for long-term certificates issuance and usage.
Up

A.4.3  Summary of risk analysis  p. 24

To prevent the identified unauthorized usages of the private key the following recommendations need to be addressed:
  • the storage of the private key and the related cryptographic computations to be done in a secure manner;
  • the solution should provide a secure path to the private key usage.
The UICC provides the most secure location for storage and usage of the private key in terms of security (in the form of, e.g. the WIM application). This does not preclude the use of other locations for certain services. On the other hand, the ME can provide a secure path to using the private key (e.g. with mechanisms such as code signing). The combination of solutions will provide a complete secure solution and enable the deployment of secure services.
Up

$  Change History  p. 25

Up   Top