COMPANY / ORGANISATION PROVIDER
Name: NEC Laboratories Europe GmbH
Address: Kurfürsten-Anlage 36, 69115 Heidelberg
The service allows users to access tokens through a scalable Kerberos-like authentication and authorisation system. The distributed system prevents user/application service credentials from being compromised by attackers, and makes the first step to outsourcing a Kerberos service into a cloud environment in order to provide more accessibility and scalability. It also offers advanced user authentication and transaction verification in mobile banking and wallet.
Kerberos (C. Neuman, July 2005) is a widely used standard protocol for authentication and authorization service that uses symmetric cryptography. The system is mainly composed of four entities:
c) authentication server (AS), and
d) ticket-granting server (TGS).
Whenever a user would like to access a service, he will authenticate himself to AS and get an authorized access token (i.e. the ticket) from TGS.
While Kerberos is a very successful and widely used standard, the service is only hosted in a closed enterprise environment, or, trusted environment, because using symmetric cryptographic, all the secret credentials and access policies are stored on AS and TGS. Therefore, Kerberos is never, and should not be used in an outsourced environment such as cloud service, in the fear of disclosing credentials to attackers from public and curious cloud system administrators. Thus Kerberos misses its opportunity to scale out its service through cloud technology. Meanwhile, other ticket-granting services based on public cryptography are not widely adopted by the public. This is because most of the small smart objects (‘service’ in the Kerberos role) have limited memory and computation capabilities, which are not so in favour of public cryptographic based protocols.
Distributed Kerberos ticket-granting service is a variant of Kerberos protocol that operates on secret-shared credentials among distributed machines. The authentication process and the ticket-issuing process are accomplished through secure multiparty computation (SMC) . This means, that the ticket is consent to be issued by multiple TGSs, and the credentials will remain secret as long as at least one server is not compromised. This is plausible as servers from multiple cloud providers can be used to reduce the risks under the attacks.
In the scenario of smart city, the services can be many smart objects (or resources) such as a printer on the campus, or a vending machine in the neighbourhood. The users can authenticate themselves to the system and get an access token from their smartphones at any time in any places. Then they just simply present the tokens to the smart objects and receive the services, such as printing service. One device could register for several services. For instance, print in grey or colour mode, or sell goods to over 18-year-old adults. In the current prototype, we only consider one type of service for the devices, and no access control policies on the TGS.
We consider a system with the following roles in the smart city scenario:
– (Authentication/Authorization) Service Provider that deploys multiple ASs and TGSs in the Cloud (e.g. IaaS);
– Resource that is provided by the service provider and is registered as service A;
– Client that wants to access resource x and will gain and present his access token in order to use service A.
The authentication protocol will be Kerberos-conform on the side of the client and the resource (or device), hence any existing Kerberos-compliant device and client does not need to be modified and therefore, will not be influenced whether the service provider decides to move the Kerberos service to the cloud or not.
We consider the setting where several cloud providers are on the market and offer the authentication services. The client and operator of the resources needs to trust that at least m out of n available servers will manage (i.e. verify or revoke) the credentials of users and devices faithfully. The current setting includes 2 available servers of which at least one operates faithfully. This scenario is illustrated in the figure below.
The credentials in the setting include the user key ku, and the resource key kr.ku is partitioned and dispatched to distributed ASs, is partitioned and dispatched to distributed TGSs. User’s request goes through a proxy that will redirect the requests further to distributed servers.
During the protocol, the keys are mainly used to encrypt/decrypt tokens. Session keys will also be generated during the process by the servers. As depicted in Figure-1, the authentication process and the token creation process are carried out by the distributed servers through secure two-party computation. As a result, all the input data, i.e., the credential keys, will remain secret during the whole computation process.
- Category: Access Control, Strong Authentication, and Trustworthy Data Storage
- Type: User authentication and authorization service
A Kerberos server is launched from entry point:
You can specify whether this server will launch with AS service, TGS service, or Proxy service by specifying the following options:
Server launch options:
Specify that the server starts AS service using configuration file
Specify that the server starts TGS service using configuration file
Specify that the server starts Proxy service using configuration file
Smckerberos-server allows the server to run maximum all 3 services with multiple threads. The configuration file “config_<service_name>.properties” can be found in the resource directory: smckerberos-server/src/main/resources. A sample configuration file is shown below:
Example of configuration file: config_as.properties:
# Service listing port
# Id of the corresponding TGS server. AS (current service) has a shared
# key with the named TGS server. The tgs_id is used to extract the
# shared key from the key store.
# Key store value
# [Only for testing] Hard-coded user key shares (expanded)
Example of configuration file: config_proxy.properties
# Proxy listening port
# List of AS/TGS addresses. Property names ‘as_1/as_2, tgs_1/tgs_2’
# should not be changed. It is just to distinguish multiple services;
# it is not really the server name. The only important is the full IP
# address of the services with format : as_1=10.13.64.215:60001
It is important to verify if the address of each server is where that server is deployed and configured. In the future this configuration part will be moved to the database hosted by the proxy.
For smckerberos-user module, the entry point is
Current prototype still contains the traces of performance evaluation test. Therefore, from StartKerberosUser, you can specify the number of users (threads) in the system to query the Kerberos service, as well as specifying the inter arrival time of the users. However, you can leave these options blank, and the default parameter will start only one user instance to request token from the Kerberos service.
In the prototype, we do not implement the device module, as it will be in the future an independent development (probably using standard Kerberos-client libraries) on the device such as NFC tag. We only have testing device credentials (dispatched to TGSs) and after user gets the token, the entry code StartKerberosUserwill simulate User <–> Device communication to validate the token.
The configuration file of the user is very simple. User only needs to know the address of the proxy like listed below:
Example of configuration file: config_user.properties
# Full address to proxy
Smckerberos-user module also contains class de.nec.nle.sec.smckerberos.prototype.local.AccountManager. It provides the functionality of expanding and partitioning the user/device credentials, as well as disbuting the key shares to the ASs and TGSs. The key-distribution procedure does not go through the Proxy, who is in the cloud and therefore not fully trusted (should not see the key shares together). As a result, the configuration files of the AccountManager contains the address lists of ASs and TGSs as in Table-5. Since that the key distribution process is not included in the Kerberos standard, we consider this part can be defined by the developers according to their own requirements.
Example of configuration file: config_admin.properties
# List of AS full address
# List of TGS full address
Prototype deployment and run
Under the <project_home>/script directory, there are three script files:
- envsetup.sh: set up the variables for any other script files.
- build.sh: build and package the project files.
- deploy.sh: deploy the executable packages and run the prototype.
Before using any script file, it is important to check the setup file envsetup.sh, especially the section to define the remote host (where your smckerberos-server component would be running). Please first verify the host IP address in envsetup.sh is the same as in the configuration file of Proxy.
To compile the project, use command: $ cd <project_home>/script; bash build.sh. The required modules are packaged along with the dependent libraries. They can be found in the following directories:
To deploy the executables, you can use script deploy.sh which gives an example about how to deploy and launch the server code: $cd <project_home>/script; bash deploy.sh. It launches the Kerberos servers on two remote hosts as listed in the table below. The log files of the server can be found in <remote_project_home>/smckerberos/output/server_[1|2].log.
Services launched by script deploy.sh
In the end, the script starts a user thread locally to request token from the remote service. It gives the output similar to this output of deploy.sh:
=====> Start remote servers…
Wait 3 sec for the server to start up.
=====> Start user
Mar 17, 2015 4:58:07 PM de.nec.nle.sec.smckerberos.prototype.local.KerberosUser registerProtocolProxy
INFO: Register Entry of the Authentication Cloud successfully.
Mar 17, 2015 4:58:09 PM de.nec.nle.sec.smckerberos.prototype.local.KerberosUser issueASRequest
INFO: Get TGT successfully.
Mar 17, 2015 4:58:11 PM de.nec.nle.sec.smckerberos.prototype.local.KerberosUser issueTGSRequest
INFO: Get SGT successfully.
Hello: User-2000. Approve:Vending_Machine-2222. Ticket request delay: =========> 3296 ms
To configure and deploy the prototype manually, you can copy the package smckerberos-server-1.0-SNAPSHOT-jar-with-dependencies.jar along with file NPOTKey in smckerberos-server/src/main/resources to a host, and launch the service as described in section 3.1:
$ java –jar smckerberos-server-1.0-SNAPSHOT-jar-with-dependencies.jar [–as <as_name> | -tgs <tgs_name> | -proxy]
For user instance, similarly, copy the package smckerberos-user-1.0-SNAPSHOT-jar-with-dependencies.jar to a host and launch the application as:
$ java –jar smckerberos-user-1.0-SNAPSHOT-jar-with-dependencies.jar
Note that before deploying the executable packages, please first verify the settings in the configuration file and build the projects, so that the configuration files included in the packages are with the correct settings.
The prototype software maintains three maven modules:
- smckerberos-common: contain the common libraries that are used by both smckerberos-server and smckerberos-user.
- smckerberos-server: implement the servers behaviour, i.e. AS, TGS, Proxy (see also Figure-1).
- smckerberos-user: implement the user behaviour to contact the proxy for ticket-granting service.
Project module dependencies:
Except for the libraries available in maven repositories that can be downloaded during compilation, the dependencies of the project are listed as above. FastGC is a library of an efficient secure two-party computation protocol based on garbled circuit. The original protocol is described in work (Yan Huang, 8-12 August 2011). In the following section we will mainly describe module smckerberos-server and smckerberos-user, and how to deploy the prototype to run it.
- Interfaces & Protocols:
The protocol can be expressed in the following steps and is depicted in the following figure: