NZ618957B2 - Service access authentication method and system - Google Patents
Service access authentication method and system Download PDFInfo
- Publication number
- NZ618957B2 NZ618957B2 NZ618957A NZ61895712A NZ618957B2 NZ 618957 B2 NZ618957 B2 NZ 618957B2 NZ 618957 A NZ618957 A NZ 618957A NZ 61895712 A NZ61895712 A NZ 61895712A NZ 618957 B2 NZ618957 B2 NZ 618957B2
- Authority
- NZ
- New Zealand
- Prior art keywords
- authentication system
- access authentication
- subscriber
- operator
- private
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0884—Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
Abstract
access authentication system for authenticating a subscriber of a service is disclosed. The access authentication system comprises an operator access authentication system (101) and one or more private access authentication systems (102). The operator access authentication system (101) is an access authentication system operated by an operator. The private access authentication system (102) is an access authentication system operated by an entity different from an operator. Each private access authentication system (102) is communicatively connectable with the operator access authentication system (101). The operator access authentication system (101) is adapted to provide one or more authentication functions for facilitating authentication of subscribers of the service based on respective subscriber authentication data items associated with credentials of the subscriber. The credentials comprise subscriber data and data indicative of an authentication algorithm and its parameters. Each private access authentication system (102) operated by the subscriber is adapted to communicate one or more subscriber authentication data items associated with the credentials of the subscriber to said operator access authentication system (101). Each private access authentication system (102) operated by the subscriber is further adapted to communicate one or more verification data items. The verification data item comprises a remote attestation data item and is indicative of the private access authentication system (102) operating in at least one predetermined state, and facilitates determination whether the at least one predetermined state is trustable by the operator access authentication system (101). ss authentication system operated by an operator. The private access authentication system (102) is an access authentication system operated by an entity different from an operator. Each private access authentication system (102) is communicatively connectable with the operator access authentication system (101). The operator access authentication system (101) is adapted to provide one or more authentication functions for facilitating authentication of subscribers of the service based on respective subscriber authentication data items associated with credentials of the subscriber. The credentials comprise subscriber data and data indicative of an authentication algorithm and its parameters. Each private access authentication system (102) operated by the subscriber is adapted to communicate one or more subscriber authentication data items associated with the credentials of the subscriber to said operator access authentication system (101). Each private access authentication system (102) operated by the subscriber is further adapted to communicate one or more verification data items. The verification data item comprises a remote attestation data item and is indicative of the private access authentication system (102) operating in at least one predetermined state, and facilitates determination whether the at least one predetermined state is trustable by the operator access authentication system (101).
Description
Service access authentication method and system
TECHNICAL FIELD
Disclosed are a system and corresponding method for authenticating access to a
service.
BACKGROUND
Many communications networks comprise functionality for controlling and granting
to subscribers access to the communications network. Typically, such access is
granted to subscriber devices subject to a verification of subscriber credentials for
authenticating said subscriber device. For example, access to many
communications systems, e.g. mobile communications network systems, is limited
to subscribers of a communications service that utilises the communications
network.
In the context of the GSM/CDMA system and similar mobile communications
systems, the mobile switching center (MSC) is the primary service delivery node,
responsible for routing voice calls and SMS as well as other services (such as
conference calls, FAX and circuit switched data). The MSC sets up and releases
the end-to-end connection, handles mobility and hand-over requirements during
the call and takes care of charging and real time pre-paid account monitoring.
Other important entities in the GSM system are the Home Location Register (HLR)
and the Authentication Centre (AuC) connected to the MSC. In a wireless network,
the HLR is the central location where user information is stored, such as account
numbers, features, preferences, permissions, etc. The Home Location Register
(HLR) was introduced in GSM as an entity that contains the functions needed to
administer and check the subscriber of the mobile network. In conjunction with the
Visitor Location Register (VLR) and the Mobile Switching Center (MSC), the HLR
enables subscribers to send and receive calls within the home network and to
6023305_3.docx
travel (“roam”) within other networks while still maintaining access to familiar and
desired services.
When the GSM system evolved into the UMTS (3G) system and recently even into
the LTE system, the HLR kept this role. Other mobile network systems like AMPS,
DAMPS, CDMA, etc have similar network entities.
Another important function of the mobile network is the authentication centre
(AuC). The AuC is connected with the HLR and provides a function to authenticate
each SIM card through which a mobile phone attempts to connect to the GSM
core network (typically when the phone is powered on and/or when making a call).
Once the authentication is successful, the HLR is used to manage the SIM and
services described above. An encryption key is also generated that is
subsequently used to protect (encrypt) wireless communications (voice, SMS, etc.)
between the mobile phone and the GSM core network.
The AuC uses subscriber data that resides locally and data that resides in the
subscriber’s SIM card (in case of UMTS and LTE it is called a USIM card), and
provides authentication mechanisms that allow the network to authenticate its
subscribers. Furthermore, the AuC and the SIM card share the knowledge of the
authentication algorithm and its parameters that will be used during the
authentication procedure. For the purpose of the present description the
subscriber data (comprising e.g. subscriber identifiers) and the authentication
algorithm/parameters are referred to as the credentials of the subscriber.
This setup has over the years proven to give a secure way of enforcing network
access control in mobile networks and has even been extended to provide security
for services such as IMS. A key component of IMS is the Home Subscriber Server
(HSS), which may be regarded as an evolved version of the HLR that provides a
much wider range of features and is meant to act as a master repository of all
subscriber and service-specific information. It combines the HLR / AuC
6023305_3.docx
(Authentication Center) functionality of GSM networks and also provides
information specifically required by the IMS network. SIM based authentication can
also be used in other access technologies, e.g. Wireless LAN where the AuC
functionality is provided by a so called AAA Server (Authentication, Authorization
and Accounting).
However, the above setup has certain logistics implications which make it difficult
for wholesale solution providers to offer consumer devices for specific services.
The main problem is that subscriber credentials must be provisioned both into the
AuC and the device. In practice the latter is solved by forcing the subscriber to
acquire a SIM card from the operator and to insert this card into the device. When
the subscriber wants to change operator he/she gets a SIM card from another
operator and removes the first SIM card and replaces it with the new one. This has
proven to be a well-functioning system for individual subscribers. However, with
the increasing use of mobile network technology for Machine to Machine (M2M)
devices like (remote) metering devices, the above setup involves a number of
disadvantages, because the provisioning of the SIM cards into the device and due
to the way one can support flexible initial selection and change of operator.
Even though a mechanism has been described in US 7149516 that allows users to
modify their own subscriber profiles by accessing a personal home location
register which is modifiable directly by a user, this approach does not address
authentication issues towards another operator network and this prior art only
allows a user to manage subscriptions that already exist; it does not provide any
mechanism that would enable the user to conveniently add remotely an entire
subscription (identities and credentials) for a new or existing device.
As explained earlier, the AuC comprises the subscriber credentials and these are
mirrored in the SIM card which is inserted into the device. Examples of subscriber
credentials comprise an IMSI (International Mobile Subscriber Identity), one or
more cryptographic keys, one or more authentication algorithms, one or more
6023305_3.docx
session key algorithms, one or more algorithm parameters. The operator will
normally request a third party (e.g. SIM card vendor) to produce a set of SIM cards
and then populates his AuC with the credentials on those cards. When a device
owner wants to use this operator’s network he receives or buys (prepaid) one of
the operator’s SIM cards. This works well for personal devices although for some
devices the removable SIM card based on UICC technology is a cost factor and is
replaced by fixed mounted SIMs.
However, there are a number of scenarios where the prior art mechanisms have
severe limitations. For example, if a utility company wants to deploy metering
devices that report data over the mobile network, the problem arises that the
manufacturer of the devices cannot know which operator the utility company wants
to use. Thus the device manufacturer cannot pre-provision operator specific
credentials into the devices and, as with traditional mobile devices, must leave this
task to the device user which in this case is the utility company. The utility
company must then do something with the devices (insert a SIM card or
reprogram them) to make them usable on the chosen operator’s network. As soon
as the devices can make contact to the operator’s network other procedures can
then be used to provision the final credentials if so needed (i.e. in case initial
contact was based on some preliminary and or group credentials).
Similar problems are found in connected consumer electronics where an end user
has a set of personal devices (phones, digital cameras, TV sets. PCs, etc) that use
mobile networks to communicate. Even with only a handful of devices, it tends to
be very cumbersome for the user to acquire separate SIM cards for each device.
One solution that has been proposed involves the so-called MCIM (Machine
Communications Identity Module), or “Soft SIM”, see 3GPP TR33.812. This
solution addresses the provisioning problem on the device side, but still has
several shortcomings on the user/network side. For example, if a user wants to
change operator for his devices, the change-of-operator protocol must be
6023305_3.docx
executed once per device. If the user has many devices, e.g. hundreds or even
thousands of remote metering devices of a utility company, this is a prohibitive
task.
SUMMARY
The present invention provides an access authentication system for authenticating
a subscriber of a service, the access authentication system comprising: an
operator access authentication system, the operator access authentication system
being an access authentication system operated by an operator; and one or more
private access authentication systems, the private access authentication system
being an access authentication system operated by an entity different from the
operator; each private access authentication system being communicatively
connectable with the operator access authentication system, the operator access
authentication system being adapted to provide one or more authentication
functions for facilitating authentication of subscribers of the service based on
respective subscriber authentication data items associated with credentials of the
subscriber, the credentials comprising subscriber data and data indicative of an
authentication algorithm and its parameters; wherein each private access
authentication system operated by the subscriber is adapted to communicate one
or more subscriber authentication data items associated with the credentials of the
subscriber to said operator access authentication system; and wherein each
private access authentication system operated by the subscriber is further adapted
to communicate one or more verification data items, the verification data item
comprising a remote attestation data item, the verification data item being
indicative of the private access authentication system operating in at least one
predetermined state, and facilitating determination whether the at least one
predetermined state is trustable by the operator access authentication system.
The present invention further provides a method of facilitating, by an operator
access authentication system, authentication of a subscriber device requesting
access to a service; the operator access authentication system being an access
6023305_3.docx
authentication system operated by an operator and adapted to provide one or
more authentication functions for facilitating authentication of subscribers of the
service based on respective subscriber authentication data items, the method
comprising: receiving a subscriber authentication data item from a private access
authentication system operated by a subscriber and communicatively connected
with the operator access authentication system, said subscriber authentication
data item facilitating the operator access authentication system to authenticate
one or more subscriber credentials, the credentials comprising subscriber data
and data indicative of an authentication algorithm and its parameter; responsive to
the received subscriber authentication data item and responsive to a verification of
a state in which the private access authentication system is operated, providing
one or more authentication functions for facilitating authentication of a subscriber
associated to said subscriber credentials.
The present invention further provides an operator access authentication system
for an access authentication system, the operator access authentication system
being adapted to provide one or more authentication functions for facilitating
authentication of subscribers of a service based on respective subscriber
authentication data items, wherein the operator access authentication system is
configured to perform the steps of the method defined in the preceding paragraph.
The present invention further provides a method of facilitating, by a private access
authentication system connected to an operator access authentication system, the
operator access authentication system being an access authentication system
operated by an operator, the private access authentication system being an
access authentication system operated by an entity different from the operator,
authentication of a subscriber device requesting access to a service; the operator
access authentication system being adapted to provide one or more authentication
functions for facilitating authentication of subscribers of the service based on
respective subscriber authentication data items, the method comprising:
communicating a subscriber authentication data item to the operator access
6023305_3.docx
authentication system, said subscriber authentication data item being indicative of
one or more subscriber credentials, the credentials comprising subscriber data
and data indicative of an authentication algorithm and its parameters and
facilitating the operator access authentication system to selectively grant or deny a
subscriber device access to the communications network; communicating at least
one verification data item, the verification data item comprising a remote
attestation data item, indicative of a state in which the private access
authentication system is operated and facilitating determination whether said state
is trustable by the operator access authentication system.
The present invention still further provides a private access authentication system
for an access authentication system, the access authentication system comprising
an operator access authentication system and at least said private access
authentication systems; wherein the private access authentication system is
adapted to perform the steps of the method of defined in the preceding paragraph.
Disclosed herein are embodiments of an access authentication system for
authenticating a subscriber of a service, the access authentication system
comprising an operator access authentication system and one or more private
access authentication systems, each private access authentication system being
communicatively connectable with the operator access authentication system, the
operator access authentication system being adapted to provide one or more
authentication functions for facilitating authentication of subscribers of the service
based on respective subscriber authentication data items associated with
credentials of the subscriber; wherein each private access authentication system
is adapted to communicate one or more subscriber authentication data items to
said operator access authentication system; and wherein each private access
authentication system is further adapted to communicate one or more verification
data items indicative of the private access authentication system operating in at
least one predetermined state.
6023305_3.docx
Hence, embodiments of the access authentication system disclosed herein
facilitate a secure provision of one or more private access authentication systems
that may provide authentication data to an operator authentication system.
Consequently, a subscriber may set up his/her private access authentication
system and thus perform the provisioning of the subscriber device credentials to
the private access authentication system. The private access authentication
system then communicates authentication data items associated with the
credentials to an operator access authentication system operated by a service
operator providing the service. This allows the operator access authentication
system to facilitate authentication of the subscriber’s devices without the need for
registering the individual subscriber devices and their associated credentials with
the operator access authentication device and without the need for modifying the
individual subscriber devices. Furthermore, the operator may establish that the
private access authentication system can be trusted, e .g trusted to handle the
credentials.
It will be appreciated that the term subscriber and subscriber device as used
herein refer to any user or user device authorised to access the service, e.g. a
communications device or any other electronic device authorised to access the
service. The term communications device is intended to comprise stationary and
portable communications equipment. The term portable communications
equipment includes all equipment such as mobile telephones, pagers,
communicators, electronic organisers, smart phones, personal digital assistants
(PDAs), handheld computers, laptop computers, or the like, using fixed/wired (e.g.
xDSL, Ethernet, optical) or wireless (e.g. CDMA, GSM, LTE, UMTS, WLAN,
WiMAX) access technology.
The service may be a communications service such as a telecommunications
service provided by a communications network. Hence, in some embodiments
access to the service may comprise access to a communications network, such as
a mobile communications network. Accordingly, the operator access or service
6023305_3.docx
authentication system may comprise an authentication centre function compatible
with the GSM system or any other suitable function for facilitating authentication of
a subscriber of the service such as a communications network. Embodiments of
the operator access authentication system may include additional functions, e.g.
functions for storing and/or managing subscriber data, e.g. an operator HLR.
Similarly, the private access authentication system may comprise an
authentication centre function compatible with the GSM system or any other
suitable function for facilitating authentication of a subscriber of the service such
as a communications network. Embodiments of the private access authentication
system may include additional functions, e.g. functions for storing and/or
managing subscriber data, e.g. a private HLR.
For example, a subscriber may set up his private access authentication system,
e.g. the subscriber’s own AuC connected to the subscriber’s own HLR, and thus
perform the provisioning of the subscriber credentials. Consequently, there is no
need to replace the credentials when changing operator. To get access to an
operator’s network, the subscriber registers his HLR/AuC at a network operator
whose existing HLR/AuC is modified to use the subscriber HLR/AuC instead when
one of the devices associated with the subscriber wants to get access to the
network or to some other service.
Generally, the term access authentication system is intended to comprise a
system comprising one or more devices of a service delivery system such as one
or more devices of a computer network or a telecommunications system, where
the access authentication system comprises functionality facilitating subscriber
authentication, e.g. responsive to a subscriber device attempting to access a
service provided by the service delivery system. In particular the authentication
system may make use of or have stored therein authentication data items and/or
subscriber credentials, e.g. credentials comprising subscriber data and data
6023305_3.docx
indicative of an authentication algorithm and its parameters for use during the
authentication procedure.
In the context of a mobile telecommunications system, embodiments of the access
authentication system may be embodied by a suitably configured AuC, HLR,
MSC/VLR and/or combinations thereof.
The term operator access authentication system is intended to refer to an access
authentication system operated by the operator of the service delivery system,
while the term private access authentication system is intended to refer to an
access authentication system operated by an entity different from an operator of
the service delivery system, e.g. by a subscriber of the service. The operator
access authentication system is thus located with the service provider, e.g. a
telecommunications service provider, while the private access authentication
system is not located with a service provider. Hence, in the context of a mobile
telecommunications system, embodiments of an operator access authentication
system may be embodied as an MSC/VLR, an operator AuC, an operator HLR, a
Mobile Management Entity (MME) or a combination thereof.
The term authentication data item is intended to refer to any data derivable from
and/or associated with the subscriber credentials stored by the access
authentication system which data allows the receiving entity to authenticate the
subscriber attempting to access the service. In particular, the authentication data
item may be derivable from subscriber data, an authentication algorithm and its
parameters that are used during the authentication procedure. An example of an
authentication data item may include a challenge or a response of a challenge
response mechanism, e.g. between the access authentication system and a
subscriber identity module of the subscriber device. For example, the
authentication data item may be derived from a shared secret and a subscriber
identity identifier, e.g. to generate a challenge/response for identification purposes,
and optionally an encryption key for use in subsequent communications.
6023305_3.docx
Even though present standards (see e.g. Network Domain Security (NDS);
Transaction Capabilities Application Part (TCAP) user security (Release 9); 3rd
Generation Partnership Project; Technical Specification Group Services and
System Aspects; 3G Security; 3GPP TS 33.204 9.0.0 (2009-12)) describe how
through secure communication two operators can exchange data, an increased
security is required in the presence of private access authentication systems.
In some embodiments, the verification data item may be an attestation data item,
e.g. of a remote attestation mechanism. The verification data item may be
indicative of the private access authentication system operating at least one
predetermined hardware and/or software component and/or indicative of the
private access authentication system operating in at least another trusted state. It
will be appreciated however, that not all state parameters of the state of the private
access authentication system may have to be verified. In some embodiments only
one or some state parameters, sufficient for establishing that the private access
authentication system operates in one of a number of possible trusted states, is
verified. Alternatively or additionally, each private access authentication system is
securely connected to the operator access authentication system allowing
verification of the private access authentication system by the operator access
authentication system.
When the private access authentication system communicates one or more
attestation data items indicative of the private access authentication system
operating a hardware and/or software acceptable by the operator access
authentication system and/or another verification data item indicative of the private
access authentication system operating in at least one predetermined state,
additional measures to combat misuse of the network are provided, thus allowing
verification and monitoring of the subscriber’s private access authentication
system. Accordingly, in some embodiments, the entity (e.g. a server computer) on
which the private access authentication system is running can be (remotely)
6023305_3.docx
verified by the chosen operator so it is booted in the correct manner and is
executing the approved (secure) software. Alternatively or additionally, the
operator access authentication system may verify that at least a subset of the
software executed by the private access authentication system is approved or
trusted by the operator access authentication system. Generally, in embodiments
of the method described herein, the operator access authentication system and/or
another verification system may receive the verification data item and verify that
the private access authentication system operates in a trusted state.
Thus, embodiments of the network access authentication system described herein
may use the roaming capabilities in the operator’s networks to introduce a private
Authentication center, optionally in connection with a private HLR. For the purpose
of the present description the private HLR will also be referred to as pHLR and the
private Authentication Centre as pAuC. The pAuC comprises the subscriber
credential data that is needed for authentication and the pHLR may contain other
subscriber data relating to the type of service and possibly device specifics.
Furthermore, embodiments of a pAuC provide functionality allowing a network
operator to verify the pAuC. The pHLR and/or pAuC may comprise a management
interface by which the owner of the pHLR/pAuC can control the pHLR/aAuC and
by which new credentials can be added, replaced/updated, or deleted in a secure
way (e.g. using a cryptographically secure connection, e.g. SSH. or a physically
secure connection e.g. IR, NFC or USB cable). For example, a subscriber device
to be added (inserted) into the pAUC/pHLR could export a copy of its credentials
or other information over such an interface.
The private authentication system may run on a trusted platform which may
implement secure boot and enforce that only approved (e.g. correctly signed) code
can execute. This can, for example, be achieved by using TCG (Trusted
Computing Group) technology where a TPM (Trusted Platform Module) or another
suitable trusted computing platform is operable to control that only correct software
components are started, see e.g. the TPM Main Specification Level 2 Version 1.2,
6023305_3.docx
Revision 103 (also available as the international standard ISO/IEC 11889).
Generally, a trusted computing platform is a computing platform suitable for the
protection and processing of private or secret data, where the computing platform
provides isolated execution environments, where software/data is protected from
external interference, and where the trusted computing platform can offer
assurances about its behaviour (hardware and software environment).
Embodiments of a trusted computing platform may thus include functionality for
sealed (e.g. encrypted) storage (e.g. of the aforementioned device credentials)
and remote attestation.
The term remote attestation refers to a process of reliably reporting the platform’s
current state to an authorized remote entity, thus allowing the remote entity to
detect changes to the computer that comprises the trusted platform. Remote
attestation may be implemented by having the hardware generate a certificate
stating what software is currently running. The computer can then present this
certificate to a remote entity to show that unaltered software is currently executing.
Remote attestation may be combined with public-key encryption so that the
information sent can only be read by the programs that presented and requested
the attestation, and not by an eavesdropper. For example, the TCG technology
supports remote attestation which can thus be used by the chosen operator to
inspect the proper functioning of the private access authentication system.
Towards this end the operator’s access authentication system may be augmented
to support such platform verification procedures. In the context of e.g. the GSM
and similar mobile communications networks, the modified operator access
authentication system may comprise a modified HLR and/or modified AuC which
will also be referred to herein as oHLR and oAuC, respectively. Hence, the
verification data item may comprise a remote attestation result generated by the
trusted platform, e.g. a digital attestation certificate generated by the trusted
platform or any other suitable signature of the trusted platform.
6023305_3.docx
In the example mentioned earlier the utility company may establish its own pHLR
and pAuC for the devices owned by (or otherwise administrated/operated by) the
utility company and the device manufacturer may pre-provision the devices and
make the data for the pHLR and pAuC available to the utility company after it has
purchased the devices (e.g. via a web portal). Alternatively, just when the device is
to become operable, at least parts of the credentials may be generated “on
request” by the device and/or the pAuC (using e.g. locally generated
random/pseudorandom values) after which the device and pAuC synchronize the
credentials over a secure interface as already discussed. Next the utility company
may register its pHLR and pAuC at the operator of choice and the operator can
charge the utility company for the use of his network using the same mechanisms
as for roaming subscribers, or, for the mechanisms for the operator’s own
subscribers, according to agreement. If/when the utility company wants to change
operator it negotiates an agreement with a new operator and then instructs its
devices to select this new operator’s network. In contrast to prior art
arrangements, this instruction could be done by a single (secured) multi-cast
message rather than per-device change of operator. On the network side all that is
needed is for the new operator to re-configure his operator access authentication
system (e.g. the new oHLR/oAUC) to “point” or re-direct authentication data
signalling to the pHLR and pAuC of the utility company. The operator that is
chosen by the utility company on the other hand wants to be able to verify that the
utility company’s pHLR/pAuC can be trusted.
Disclosed embodiments relate to different aspects including the setup of
interacting operator and private HLR/AuCs described above and in the following,
corresponding systems, methods, and products, each yielding one or more of the
benefits and advantages described in connection with one of the above-mentioned
aspects, and each having one or more embodiments corresponding to the
embodiments described in connection with at least one the above-mentioned
aspects.
6023305_3.docx
More specifically, according to another aspect, a method is disclosed for
facilitating, by an operator access authentication system, authentication of a
subscriber device requesting access to a service; the operator access
authentication system being adapted to provide one or more authentication
functions for facilitating authentication of subscribers of the service based on
respective subscriber authentication data items, the method comprising:
• receiving a subscriber authentication data item from a private access
authentication system communicatively connected with the operator access
authentication system, said subscriber authentication data item being
indicative of one or more subscriber credentials;
• responsive to the received subscriber authentication data item and
responsive to a verification of a state in which the private access
authentication system is operated, providing one or more authentication
functions for facilitating authentication of a subscriber associated to said
subscriber credentials.
The one or more authentication functions for facilitating authentication of a
subscriber provided by the operator authentication system may include performing
an authentication process and/or forwarding authentication data, e.g. the received
authentication data item or data derived therefrom, to another entity which in turn
may perform the actual authentication process and provide access to said service.
The verification of the state in which the private access authentication system is
operated may be performed at least partly by the operator access authentication
system, e.g. responsive to a verification data item received from the private access
authentication system. Alternatively or additionally the verification may be
performed at least partly by another entity, e.g. a verification system which system
may then communicate the verification result or an intermediate result to the
operator access authentication system.
Further disclosed herein is a method of facilitating, by a private access
authentication system connected to an operator access authentication system,
6023305_3.docx
authentication of a subscriber device requesting access to a service; the operator
access authentication system being adapted to provide one or more authentication
functions for facilitating authentication of subscribers of the service based on
respective subscriber authentication data items, the method comprising:
• communicating a subscriber authentication data item to the operator access
authentication system, said subscriber authentication data item being
indicative of one or more subscriber credentials and facilitating the operator
access authentication system to selectively grant or deny a subscriber
device access to the communications network;
• communicating at least one verification data item indicative of a state in
which the private access authentication system is operated and facilitating
determination whether said state is trustable by the operator access
authentication system.
The private authentication system may communicate the subscriber authentication
data item to the operator access authentication system directly or via another
entity. The private authentication system may communicate the verification data
item to the operator access authentication system and/or to another system for
verification of the state of the private access authentication system.
Further disclosed are an operator access authentication system and a private
access authentication system for use in a service access authentication system as
defined herein. Each of the operator access authentication system and the private
authentication system may be embodied as a server, e.g. a server computer or
other data processing system or as a virtualised server using a suitable hardware
virtualisation mechanism known as such in the art.
In the description in this specification reference may be made to subject matter
which is not within the scope of the appended claims. That subject matter should
be readily identifiable by a person skilled in the art and may assist in putting into
practice the invention as defined in the presently appended claims.
6023305_3.docx
BRIEF DESCRIPTION OF THE DRAWINGS
The above and other aspects will be apparent and elucidated from the
embodiments described in the following with reference to the drawing in which:
Fig. 1 shows a schematic block diagram of an example of an authentication
system.
Fig. 2 illustrates an embodiment of a process for access authentication and
platform verification.
Fig. 3 illustrates a flow diagram of an example of a process of routing requests for
authentication data items to a private authentication system.
DETAILLED DESCRIPTION
Fig. 1 shows a schematic block diagram of an example of an access
authentication system. The access authentication system of fig. 1 is a network
access authentication system facilitating authentication of subscriber devices that
request access to a communications network such as a mobile
telecommunications network. The network authentication system comprises an
operator access authentication system 101 embodied as an operator
authentication centre (oAuC) and a private access authentication system 102
embodied as a private authentication centre (pAuC). It will be appreciated,
however, that the operator access authentication system 101 may be embodied as
an operator authentication centre (oAuC), an MSC/VLR, an operator HLR (oHLR),
or a combination thereof, and a private access authentication system 102 may
embodied as a private authentication centre (pAuC), a private HLR, or a
combination thereof.
6023305_3.docx
The pAuC may be connected to a private home location register (pHLR) 103.
Alternatively, the pAuC may be embodied as a component of a private home
location register pHLR operated by a subscriber. Similarly, the oAuC of fig. 1 is
operated by a network operator and may be connected to an operator Home
Location Register (oHLR) 104. It will be appreciated that, even though only a
single one of each of the above entities is shown in fig. 1, embodiments of an
access authentication system may comprise respective pluralities of one, some or
each of these entities. Furthermore, in some embodiments, the subscriber may
only operate a pAuC operable to communicate with an oHLR of the operator. In
this case, the IMSI may be associated with the oHLR and a request for
authentication data would first be sent to the oHLR. The oHLR may then have
information that the authentication data items should be requested from the pAuC
(e.g. an URL, IP address or similar of the pAuC is configured in the oHLR), but all
other functions may then be done at the oHLR.
The pAuC is a system, e.g. a device or a hardware and/or software component of
a device, that provides functionality for facilitating authentication of a subscriber
device 105 that attempts to connect to a mobile communications network, e.g. a
GSM network, via a base station 106 and a mobile switching centre (MSC) 107. In
some embodiments, the authentication system may perform the authentication
directly, while in other embodiments, the authentication system may instead
generate data for use in the authentication process. For example, in the context of
GSM, the pAuC may generate so-called triplets or vectors for the MSC to use
during the authentication procedure. In the case of e.g. Wireless LAN access
operating in accordance with 3GPP TS 33.234; on the other hand, the
authentication decision (accept/reject) could be made at least partly by the pAuC
itself.
The subscriber device 105, e.g. a mobile telephone, a computer, or any other
electronic device that can access the communications network, comprises a
subscriber identity module (SIM) 108. The SIM comprises subscriber credentials
6023305_3.docx
for use in the authentication process. It will be appreciated, however, that the
subscriber device may comprise any other suitable storage medium for securely
storing subscriber credentials. Examples of suitable mechanisms for storing
subscriber credentials include a “Soft SIM” type of solution, a physical UICC card,
and “hard-wired” credentials built into the device by the device manufacturer or
even credentials stored in a (protected) file on the device. Even though only a
single subscriber device is shown in fig. 1, it will be appreciated that embodiments
of a network access authentication system may provide access authentication to a
plurality of subscriber devices, each with their own credentials and means for
storage of said credentials.
The security of the authentication process may depend upon a shared secret
between the pAuC and the SIM. Accordingly, the pAuC also comprises a storage
medium 110 for storing subscriber credentials. The shared secret may be securely
burned or otherwise programmed into the SIM during manufacture and is also
securely replicated onto the pAUC. This shared secret is thereafter normally never
transmitted between the pAUC and SIM, but rather combined with the IMSI to
produce a challenge/response for identification purposes and an encryption key for
use in over the air communications.
Hence, as will be appreciated from the above, the authentication capability of the
pAuC may be similar to that of a normal AuC of prior art communications
networks. However, the pAuC is now owned and operated by the subscriber and
not by an operator. Yet the pAuC is, like in a roaming setup, responsible for
providing the authentication data items leading to access to the mobile network.
As the subscriber operates its own AuC, the subscriber can perform the
provisioning of the subscriber credentials and there is no need to replace the
credentials when changing operator. To get access to an operator’s network the
subscriber registers his/her pAuC at a network operator whose existing oHLR
and/or oAuC is modified to use the subscriber pAuC instead when one of the
subscriber devices wants to get access to the network. Thus, in some
6023305_3.docx
embodiments, the oHLR may selectively, and responsive to the identity of the
requesting subscriber device, contact the oAuC or the pAuC to obtain
authentication data for said subscriber device. In alternative embodiments, the
oHLR may always contact the oAuC which in turn may, dependent on the identity
of the subscriber device, forward the request for authentication data to a
corresponding pAuC.
The pAuC runs on a trusted (execution) platform 109. The pHLR may run on the
same or a similar trusted platform 111. A platform is referred to as “trusted”, if it is
capable in securing the execution of authorized (e.g. correctly signed) software,
e.g. based on an immutable root of trust function in the platform (e.g. the hardware
of a virtualized computation platform). In one embodiment, the trusted platform
further provides functionality allowing a remote entity to securely verify that the
platform has started in the correct manner and is running the correct software
and/or is otherwise operated in trusted state. Such functionality is often called
(platform) attestation. Several techniques for secure boot based on a root of trust
exist.
For example, the trusted platform may comprise a Trusted Platform Module (TPM)
implementing TCG (Trusted Computing Group) technology. The TPM (Trusted
Platform Module) may control that only correct software components are started.
The TCG technology also supports remote attestation which can be used by the
chosen operator to inspect the proper functioning of the pAuC. In particular, the
TPM contains the keys and mechanisms for the verification of the software
components to be started and to perform attestation of its state (see e.g. TCG
Specification, Architecture Overview, Specification, Revision 1.3, March 2007).
Alternatively or additionally, other solutions, for example the TrustZone technology
(see e.g. “ARM Security Technology, Building a Secure System usingTrustZone®
Technology”, ARM Whitepaper,
http://infocenter.arm.com/help/topic/com.arm.doc.prd29-genc-009492c/PRD29-
GENC-009492C_trustzone_security_whitepaper.pdf), may be used for secure
6023305_3.docx
boot. Alternatively or additionally, proprietary attestation protocols can be used as
well. The attestation functions may be combined with, for example, a verification of
the validity of a platform cryptographic certificate. Combinations of one or more of
such solutions may generally be referred to as platform verification. For the
purpose of the present description, the term platform verification may at least
comprise the verification of a platform certificate, e.g. using OCSP (see e.g. RFC
2560, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol –
OCSP).
As another option, the operator could provide the executable code implementing
the pAuC functionalty. This could be done by using other techniques part of the
TPM standards, known as sealing. Here, the code is sent in encrypted form (e.g.
from the oHLR 104) to the pAuC 102. The code can only be decrypted by a key
known (only) to the TPM 109. Moreover, the TPM 109 locally verifies that the
pAuC is in a trusted state before allowing decryption and subsequent execution of
the pAuC code. In this embodiment, the operator knows that the code is trusted
(since the operator wrote the code) and can trust that the code will only be
executed in allowable/trusted states.
It will be appreciated that the above platform verification mechanisms more
genrally allow the pAuC to be run in “The Cloud” which may have advantages from
an availability point of view, in particular for personal users. The pAuC may then
be a virtual machine (VM) that may migrate between different physical platforms
while the platform trust can be remotely verified as discussed herein. For example,
a so called hypervisor or virtual machine monitor (e.g. XEN or KVM) may be used
to provide a virtual machine with its own operating system running only the
pAuC/pHLR, thereby further increasing security, by isolating the pAuC/pHLR from
other (potentially erroneous or malicious) software running on the same physical
host computer.
6023305_3.docx
The remote entity that performs the platform verification process of the trusted
platform 109 (and optionally the platform 111) may be the oAuC or another
suitable component of the operator network infrastructure, e.g. the operator HLR
or some node responsible for security management, e.g. a policy enforcement
function. Accordingly, the oAuC and/or another operator network infrastructure
component may be adapted to support such platform verification procedures. The
attestation may take place when the pAuC and/or pHLR is initially connected with
the oAuC/oHLR and/or be repeated intermittently, e.g. once per authentication
data item request, once per added credential/device, once per day, etc, depending
on policy and/or agreement between user and operator.
When a subscriber device 105 requests access to the operator’s network via a
base station 106, and the operator detects that the subscription is related to a
subscriber device authentication of which is not managed by the oAuC, the
operator contacts the pAuC and requests the authentication vectors associated
with the subscriber credentials of the subscriber device 105. Detection that the
subscription is associated with an pAuC/pHLR may be done by the MSC, by the
oHLR or by the oAuC. In case a special IMSI format is used for subscriptions
associated with pAuC/pHLRs, the detection could be made by the MSC. If, on the
other hand, the IMSI is associated with a normal operator’s IMSI space, the
detection may need to be done either at the oHLR or oAuC. In either case, the
entity which detects that the subscription is related to a pAuC/pHLR may then be
configured with the address (e.g. URL or IP address) of the associated
pAuC/pHLR.
In order to achieve an efficient system this request may be combined with a
platform verification request that may use the attestation capability of the trusted
platform 109. The combined authentication vector request may be formed as
New auth vect req ={old auth vect req, nonce, proof_request} (1)
6023305_3.docx
Where proof_request indicates the type of proof the oAuC (or in general, the entity
requesting the attestation) wants to receive from the pAuC. Preferably the above is
signed by the oAuC so the pAuC can verify the origin of the request. The nonce is
introduced to prevent replay attacks. The old_auth_vect_req may be a
conventional request for authentication vectors from an AuC known as such.
The pAuC may then respond to the above request by the following combined
authentication response:
New auth vect resp ={auth vector(s), proof_answer, sign_pAuC} (2)
The pAuC signature sign_pAuC may be over auth vector(s), proof_answer, and
the nonce. This allows the receiving entity to verify the correct origin of the data
and that the data is not a repetition. It may be noted that the proof_answer may
include TPM signatures of possible attestation requests (depending on the actual
proof_request). It will be appreciated, however, that the actual details of the
proof_request and proof_answer depend on the details of how the pAuC can
prove that it is authentic and running the correct software. Signing can be done
using any public key cryptographic signing method, e.g. based on RSA or on
Elliptic curves. It will further be appreciated that the pAuC may send the above
response to the oHLR which may comprise functionality for performing platform
verification. In some embodiments, the response may be sent to the oHLR via a
pHLR associated with the pAuC.
Fig. 2 illustrates an embodiment of a process for access authentication and
platform verification using a combined authentication vector request and
pHLR/pAuC verification. The process may be performed by a network
authentication system, e.g. the system described in fig. 1 comprising an oAuC
101, an oHLR 104, and a pAuC 102. In the example of fig. 2, the platform
verification is performed by the oHLR 104 and is based on TCG TPM technology.
6023305_3.docx
Accordingly, the pAuC 102 is executed on a TPM 109. Alternatively, the platform
verification may be performed by another network entity, e.g. the oAuC.
The process may be initiated by the oHLR although it may be implemented as a
new subfunction of an existing HLR, or it could even be made part of the oAuC.
For the purpose of the present description, it is assumed that the trigger originates
from the oHLR itself.
The oHLR sends a request for authentication data 221including a verification
request , e.g. of the form (1) described above, to the pAuC associated with the
subscriber device requesting access to the network. As described above, the
request includes a verification request in the form of a command, denoted
proof_request, to the pAuC to construct a proof. For example, the request may ask
for proofs of the presence of certain subsystems in the pAuC. For the purpose of
simplicity of the present description, the request is assumed to be for a proof that
the pAuC is booted correctly and that it has knowledge of a pAuC authentication
subsystem private key. It will be appreciated that, in some embodiments, an
attestation request may be issued for each request for authentication data so as to
provide a high level of security, while in other embodiments the attestation request
may be issued intermittently instead and/or in addition to requests associated with
a request for authentication data.
Upon receipt of the request 221, the pAuC uses the TPM 109 to generate a proof
that it was booted correctly. In fig. 2, this is illustrated by an attestation request 222
communicated by the pAuC to the TPM 109. This is a known procedure as such
and specified in the TCG specifications (see e.g. TCG Specification, Architecture
Overview, Specification, Revision 1.3, March 2007). The proof is returned to the
pAuC by the TPM as the attestation result 223. The attestation request may
comprise a random challenge which may be the nonce from the message 221 sent
by the oHLR, or it can be a function of this nonce and the auth vector data.
6023305_3.docx
The pAuC may now construct the proof_answer as being the tuple:
Proof_answer = {
boot_proof: attestation result;
pAuC_auth_private_key_proof: RSA_signature;
Where the RSA_signature is a signature of the earlier mentioned nonce.
Note that the sign_pAuC shown in Fig. 2 may be based on another private key
than the private key of the authentication subsystem, e.g. it may be the private key
related to a roaming agreement between the pHLR and the oHLR.
The pAuC then returns an authentication response 224 e.g. of the form (2)
described above, including the proof_answer to the oHLR.
The oHLR may then use an OCSP server 225 to check whether certificates have
been revoked, as illustrated by messages 226 and 227. Alternatively the oHLR
may rely on distributed Certificate Revocations Lists that are distributed.
If the verification of the pAuC is successful, the oHLR may process the auth_vect
in a manner known as such, e.g. as is normally done for a roaming user.
In order to facilitate the provision of subscriber-operated authentication systems,
the network infrastructure may be modified to provide routing of requests for
subscriber authentication data to the correct pHLR/pAuC. For example, this
process may as mentioned be performed by the MSC/VLR of the operator of the
base station via which the subscriber device attempts to access the network. The
routing may be accompanied by a secure connection (e.g. IPsec or TLS/SSL) set-
up for a subsequent transfer of authentication data (so called authentication
vectors) using e.g. Radius or Diameter.
6023305_3.docx
The operator may know which IMSI numbers are related to which pAuC. In the
case of non-roaming devices the simple solution shown in Fig. 3 may be used.
This method introduces an additional step 331 in the routing resolution by
identifying the IMSIs that belong to one of the pAuCs that are registered. By
using, for example, hash tables this look-up can be implemented efficiently in
basically constant time complexity. In the example of fig. 3, the process initially
determines in step 330 whether the MCC (Mobile Country Code) and MNC (Mobile
Network Code) part of the IMSI point to another operator. If this is the case, the
process contacts the identified other operator. Otherwise, in step 331, the process
identifies a pAuC associated with the IMSI.
Note that the 15 digit IMSI may not be sufficient when every user may have a
pAuC and many devices associated with that pAuC. Therefore, as an option, the
following approach may be used.
When the VPLMN (Visible Public Land Mobile Network) detects that the
MCC+MNC points to a pAuC/pHLR, the MSIN part is used to identify the
pAuC/pHLR and the VPLMN also issues a second identity request (IMSI requests
may be issued at any time when the network does not have sufficient information
to identify the subscriber according to 3GPP specifications) to identify the device
within this pAuC/pHLR. This means that up to 1 Billion pAuC/pHLRs can be
supported, each with Billions of devices.
Note that the detection of the pAuCs can be placed prior to the existing
procedures. In cases where the devices also need to roam into other networks the
same routing information may be distributed to other operators.
Although some embodiments have been described and shown in detail, the
invention is not restricted to them, but may also be embodied in other ways within
the scope of the subject matter defined in the following claims.
6023305_3.docx
The method, product means, and device described herein can be implemented by
means of hardware comprising several distinct elements, and by means of a
suitably programmed microprocessor. In the device claims enumerating several
means, several of these means can be embodied by one and the same item of
hardware, e.g. a suitably programmed microprocessor, one or more digital signal
processor, or the like. The mere fact that certain measures are recited in mutually
different dependent claims or described in different embodiments does not indicate
that a combination of these measures cannot be used to advantage.
It should be emphasized that the term "comprises/comprising" when used in this
specification is taken to specify the presence of stated features, integers, steps or
components but does not preclude the presence or addition of one or more other
features, integers, steps, components or groups thereof.
It should be noted that although the ideas have been described in the setting of
controlling and granting access to networks it will be appreciated that the disclosed
methods and systems can be used to control and grant access to services in
general.
6023305_3.docx
Claims (24)
1. An access authentication system for authenticating a subscriber of a service, the access authentication system comprising: 5 an operator access authentication system, the operator access authentication system being an access authentication system operated by an operator; and one or more private access authentication systems, the private access authentication system being an access authentication system operated by an 10 entity different from the operator; each private access authentication system being communicatively connectable with the operator access authentication system, the operator access authentication system being adapted to provide one or more authentication functions for facilitating authentication of subscribers of the service based on 15 respective subscriber authentication data items associated with credentials of the subscriber, the credentials comprising subscriber data and data indicative of an authentication algorithm and its parameters; wherein each private access authentication system operated by the subscriber is adapted to communicate one or more subscriber authentication data 20 items associated with the credentials of the subscriber to said operator access authentication system; and wherein each private access authentication system operated by the subscriber is further adapted to communicate one or more verification data items, the verification data item comprising a remote attestation data item, the verification data item being indicative of the private access 25 authentication system operating in at least one predetermined state, and facilitating determination whether the at least one predetermined state is trustable by the operator access authentication system.
2. An access authentication system according to claim 1, wherein each private 30 access authentication system is securely connected to the operator access 6023305_3.docx authentication system allowing verification of the private access authentication system by the operator access authentication system.
3. An access authentication system according to claim 1 or 2, wherein the 5 private access authentication system comprises a trusted platform.
4. An access authentication system according to claim 3, wherein the trusted platform is operable to perform a secured boot operation. 10
5. An access authentication system according to claim 4 or 5, wherein the trusted platform is operable to restrict execution of program code to digitally signed program code.
6. An access authentication system according to any one of claims 3 through 5, 15 wherein the verification data item comprises at least one signature of the trusted platform or at least one attestation result generated by the trusted platform.
7. An access authentication system according to any one of the preceding claims, wherein the private access authentication system is adapted to 20 communicate an authentication message comprising the subscriber authentication data item and one or more verification data items.
8. An access authentication system according to claim 7, wherein the private access authentication system is adapted to receive a request for authentication 25 data from the operator access authentication system, and to communicate the authentication message responsive to the request for authentication data.
9. An access authentication system according to claim 8, wherein the request for authentication data comprises a nonce, and wherein the private access 30 authentication system is adapted to include at least a digital signature over at least the received nonce in the authentication message. 6023305_3.docx
10. An access authentication system according to claim 8 or 9, wherein the request for authentication data comprises a data item indicative of a type of proof requested by the operator access authentication system to indicate that the private 5 access authentication system is operating in at least one predetermined state.
11. An access authentication system according to any one of claims 7 through 10, wherein the authentication message comprises a digital signature. 10
12. An access authentication system according to any one of the preceding claims, wherein the at least one predetermined state comprises the private access authentication system executing a predetermined software component trusted by the operator access authentication system. 15
13. A method of facilitating, by an operator access authentication system, authentication of a subscriber device requesting access to a service; the operator access authentication system being an access authentication system operated by an operator and adapted to provide one or more authentication functions for facilitating authentication of subscribers of the service based on respective 20 subscriber authentication data items, the method comprising: receiving a subscriber authentication data item from a private access authentication system operated by a subscriber and communicatively connected with the operator access authentication system, said subscriber authentication data item facilitating the operator access authentication system to authenticate 25 one or more subscriber credentials, the credentials comprising subscriber data and data indicative of an authentication algorithm and its parameter; responsive to the received subscriber authentication data item and responsive to a verification of a state in which the private access authentication system is operated, providing one or more authentication functions for facilitating 30 authentication of a subscriber associated to said subscriber credentials. 6023305_3.docx
14. A method according to claim 13, comprising: forwarding a request for authentication data to the private authentication system; receiving the subscriber authentication data item responsive to said request.
15. A method according to claim 13 or 14, further comprising: receiving at least one verification data item by the operator access authentication system from the private access authentication system, the verification data item being indicative of a state in which the private access 10 authentication system is operated; determining by the operator authentication system, based on the received verification data item, whether said state is trustable by the operator access authentication system; and wherein providing one or more authentication functions is responsive to 15 said determination.
16. An operator access authentication system for an access authentication system, the operator access authentication system being adapted to provide one or more authentication functions for facilitating authentication of subscribers of a 20 service based on respective subscriber authentication data items, wherein the operator access authentication system is configured to perform the steps of the method of any one of claims 13 through 15.
17. An operator access authentication system according to claim 16, further 25 configured to: receive a service request from a subscriber device; identify, based on the received request, one of a set of private access authentication systems; and request from the identified private access authentication system the at least 30 one verification data item indicative of a state in which the private access authentication system is operated, and the subscriber authentication data item 6023305_3.docx indicative of one or more subscriber credentials associated with said subscriber device.
18. A method of facilitating, by a private access authentication system connected 5 to an operator access authentication system, the operator access authentication system being an access authentication system operated by an operator, the private access authentication system being an access authentication system operated by an entity different from the operator, authentication of a subscriber device requesting access to a service; the operator access authentication system 10 being adapted to provide one or more authentication functions for facilitating authentication of subscribers of the service based on respective subscriber authentication data items, the method comprising: communicating a subscriber authentication data item to the operator access authentication system, said subscriber authentication data item being indicative of 15 one or more subscriber credentials, the credentials comprising subscriber data and data indicative of an authentication algorithm and its parameters and facilitating the operator access authentication system to selectively grant or deny a subscriber device access to the communications network; communicating at least one verification data item, the verification data item 20 comprising a remote attestation data item, indicative of a state in which the private access authentication system is operated and facilitating determination whether said state is trustable by the operator access authentication system.
19. A private access authentication system for an access authentication system, 25 the access authentication system comprising an operator access authentication system and at least said private access authentication systems; wherein the private access authentication system is adapted to perform the steps of the method of claim 18. 6023305_3.docx
20. An access authentication system for authenticating a subscriber of a service, the access authentication system being substantially as hereinbefore described with reference to the accompanying drawings. 5
21. A method of facilitating, by an operator access authentication system, authentication of a subscriber device requesting access to a service; the operator access authentication system being an access authentication system operated by an operator and adapted to provide one or more authentication functions for facilitating authentication of subscribers of the service based on respective 10 subscriber authentication data items, the method being substantially as hereinbefore described with reference to the accompanying drawings.
22. An operator access authentication system according to claim 16, the operator access authentication system being substantially as hereinbefore described with 15 reference to the accompanying drawings.
23. A method of facilitating, by a private access authentication system connected to an operator access authentication system, the private access authentication system being an access authentication system operated by an entity different from 20 an operator, the operator access authentication system being an access authentication system operated by an operator, authentication of a subscriber device requesting access to a service; the operator access authentication system being adapted to provide one or more authentication functions for facilitating authentication of subscribers of the service based on respective subscriber 25 authentication data items, the method being substantially as hereinbefore described with reference to the accompanying drawings.
24. A private access authentication system according to claim 19, the private access authentication system being substantially as hereinbefore described with 30 reference to the accompanying drawings. 6023305_3.docx P33506 WO1 P33506 WO1
Applications Claiming Priority (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP11170110.8 | 2011-06-16 | ||
EP11170110.8A EP2536095B1 (en) | 2011-06-16 | 2011-06-16 | Service access authentication method and system |
US201161498798P | 2011-06-20 | 2011-06-20 | |
US61/498,798 | 2011-06-20 | ||
PCT/EP2012/061176 WO2012171946A1 (en) | 2011-06-16 | 2012-06-13 | Service access authentication method and system |
Publications (2)
Publication Number | Publication Date |
---|---|
NZ618957A NZ618957A (en) | 2015-12-24 |
NZ618957B2 true NZ618957B2 (en) | 2016-03-30 |
Family
ID=
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9432349B2 (en) | Service access authentication method and system | |
US11431695B2 (en) | Authorization method and network element | |
US10917790B2 (en) | Server trust evaluation based authentication | |
KR101838872B1 (en) | Apparatus and method for sponsored connection to wireless networks using application-specific network access credentials | |
JP6262278B2 (en) | Method and apparatus for storage and computation of access control client | |
KR101840180B1 (en) | Apparatus and method for sponsored connection to wireless networks using application-specific network access credentials | |
KR101611773B1 (en) | Methods, apparatuses and computer program products for identity management in a multi-network system | |
EP3657835B1 (en) | Access method of user equipment, user equipment and computer-readable storage medium | |
US20180294949A1 (en) | EMBEDDED UNIVERSAL INTEGRATED CIRCUIT CARD (eUICC) PROFILE CONTENT MANAGEMENT | |
US20160057725A1 (en) | Security method and system for supporting re-subscription or additional subscription restriction policy in mobile communications | |
WO2018202284A1 (en) | Authorizing access to user data | |
US20120233685A1 (en) | Method for authentication of a remote station using a secure element | |
US9537663B2 (en) | Manipulation and restoration of authentication challenge parameters in network authentication procedures | |
US11070355B2 (en) | Profile installation based on privilege level | |
US11228428B2 (en) | Mitigation of problems arising from SIM key leakage | |
WO2021031051A1 (en) | Mobile device authentication without electronic subscriber identity module (esim) credentials | |
NZ618957B2 (en) | Service access authentication method and system | |
US20230319573A1 (en) | Profile transfer with secure intent | |
WO2016162759A2 (en) | Secure service request using an application granted key |