WO2017108226A1

WO2017108226A1 - Data security

Info

Publication number: WO2017108226A1
Application number: PCT/EP2016/074795
Authority: WO
Inventors: Robert Elgaard
Original assignee: Sdc A/S
Priority date: 2015-12-23
Filing date: 2016-10-14
Publication date: 2017-06-29
Also published as: EP3394809A1; GB201522762D0

Abstract

Disclosed herein is a method of authorising an action at a first computer system. The method comprises receiving a new authorisation code at the first computer system, wherein the new authorisation code is generated from a previous authorisation code by a second computer system, authenticating the new authorisation code, and authorising an action following successful authentication of the new authorisation code. A computer-readable medium for implementing this method is also disclosed.

Description

Data security

Field of Invention

This disclosure relates to a method for generating a new authorisation code for data security. More specifically, but not exclusively, a method for dynamically updating user login information is disclosed, which is arranged to improve security of data communications.

Background to the Invention

The internet enables users to buy and sell goods and services online by utilising online electronic transactions to enable a buyer or payer to send money electronically to the seller or payee who then receives the money. In order for such e-commerce transactions to occur online between a payer and payee it is necessary for at least some financial information to be exchanged over the internet.

The volume of e-commerce transactions has been constantly on the rise in recent years and, compared to traditional payment methods such as payment by debit or credit card in person, or payment by cheque, the benefits of e-commerce include on-demand availability, speed of access, accessibility and global reach. However, all this comes with the risk of reduced security and privacy and, furthermore, requires lots of manual data entry. For example, users are faced with the exasperating task of entering their personal and financial details each time they shop online.

Moreover, for each of these transactions, they are at risk of web hackers stealing their personal and financial details. The use of mobile phones for e-commerce (so-called m-commerce) raises the potential threat of data theft to a higher level because users may additionally have to exchange financial data over a mobile wireless network. Together, these risks and tasks keep many users away from shopping online and act as an obstacle for the further development of e-commerce and m- commerce.

One proposal for improving the security and privacy of e-commerce and m-commerce transactions is to encrypt transaction communications and implement security technologies such as the Secure Sockets Layer (SSL). However, such encryption techniques are still vulnerable to attack and provide little or no protection against attacks based on key-logging.

Another proposal is to use a web fraud detection system that looks for unusual behaviour in a user's transaction activities. However, this is a reactive approach that detects fraudulent use after a user's financial information has been stolen and used, which is less than ideal. The issue of e-commerce and m-commerce fraud remains a huge problem and there are still inadequate measures in place to protect consumer's financial information online. These issues effectively extend to any online activity in which a user has to identify themselves using log-in information or such like, which is usually indicative of there being some personal data being shared after a login is successful.

Summary of Invention

According to an aspect of the disclosure, a method of authorising an action at a first computer system is disclosed. The method comprises receiving a new authorisation code at the first computer system, wherein the new authorisation code is generated from a previous authorisation code by a second computer system, authenticating the new authorisation code, and authorising an action following successful authentication of the new authorisation code.

The new authorisation code may be sent to the first computer system by the second computer system. The second computer system may have generated the new authorisation code. The second computer system may be the system requesting an action to be performed.

The new authorisation code may be sent to the first computer system by a third computer system. The third computer system may be a system arranged to generate such authorisation codes.

The new authorisation code may be generated from the previous authorisation code and an additional input. The new authorisation code may be generated by concatenating the previous authorisation code to the additional input to create a concatenated expression, and calculating a hash value over the concatenated expression. The new authorization code may be the resultant hash value.

The additional input may comprise a passcode. The passcode may be generated by the first computer system and sent to the second computer system for generating the new authentication code. The passcode may be received by the first computer system having been generated by a computer system other than the first computer system. The use of a passcode may assist to increase security. If the passcode is generated via a separate device utilising a further communication channel then the risk of a security breach is reduced.

The step of authenticating the new authorisation code may comprise comparing the new authorisation code with an authenticating authorisation code. The authenticating authorisation code and the new authorisation code may be generated by the first and second computer systems respectively using the same method. The authorised action may comprise a financial transaction. The method may further comprise sending, from the first computer system, confirmation of the authorisation of an action following successful authentication of the authorisation code.

The first computer system may authenticate the new authorisation code. The first computer system may send confirmation of the authorisation of an action following successful authentication of the authorisation code to the second computer system.

The method may further comprise receiving a further authorisation code at the first computer system, wherein the further authorisation code is generated from the new authorisation code by the second computer system, authenticating the further authorisation code, and authorising an action following successful authentication of the further authorisation code.

The method may further comprise receiving, prior to receiving the new authorisation code, a first authorisation code at the first computer system, wherein the first authorisation code is generated from an initialisation code by the second computer system, authenticating the first authorisation code, and authorising an action following successful authentication of the first authorisation code.

The initialisation code may comprise one or more of a social security number, a company registration number, a personal identification code and a location identifier such as the country code of a place of residence of a user associated with the second device.

Also disclosed is a computer-readable medium comprising instructions that are executable by a processor to perform any method disclosed herein.

Also disclosed is a server comprising a memory arranged to store computer-implementable code arranged, in use, to implement any method disclosed herein, and a processor arranged to implement the code stored in the memory.

The passcode may be provided via over the air standard provisioning. The passcode may be a random code. The passcode may be a one-time passcode. The passcode may be provided via mobile internet. The passcode may be provided via short message service (SMS). The new authorisation code may be stored encrypted under a symmetric encryption key. The hash value may be calculated using a SHA-2 hash function. The second computer system may be a smartphone or tablet device. The first computer system may be a server. The authenticating authorisation code may be stored in memory of the first computer system.

The creation of the dynamic user ID involves concatenating a first code or reference with a second code or reference, wherein one of the first or second code or reference is the previous dynamic user ID. The user ID may be generated independently by both first and second computer systems. Both systems may use the same parameters for the generation in order to ensure that the user ID that they have generated remain identical.

Brief Description of the Drawings

Exemplary arrangements of the disclosure shall now be described with reference to the drawings in which:

Figure 1 illustrates an electronic transaction system in accordance with the present disclosure; and Figure 2 illustrates a process for managing the log-in process between entities of the system of Figure 1.

Throughout the description and the drawings, like reference numerals refer to like parts.

Specific Description

An arrangement shall now be discussed in detail which relates to a method for dynamically updating a user's ID for securely making purchases from an e-commerce site. By providing such a dynamic updating, the security of the user's account is improved.

The structure of the system used for providing the dynamic user ID functionality shall firstly be described with reference to Figure 1. The method used to dynamically update the user ID on the system of Figure 1 shall then be discussed with reference to Figure 2.

Figure 1 illustrates a system 100 known herein as the proxyPay system. The system 100 comprises a server 1 10, referred to as the proxyPay server, a consumer device 120, or payer device, and a merchant device 130, or payee device.

The server 1 10 is a first computer system that acts an interface device for transactions between the consumer device 120 and the merchant device 130 in order to increase security.

The consumer device 120 which is a second computer system is a smart phone in this arrangement, but may be any other type of computer system such as a desktop computer or tablet.

The merchant device 130 is a third computer system within the system 100 associated with a specific merchant such as an online shop. Each entity within the system is a computing system at least comprising a processor, a memory, and a communications port. Each has software operating thereon to enable methods disclosed herein to be performed on the devices. In particular, the software on the consumer device 120 is a smartphone app, referred to herein as the proxyPay app.

The server 1 10, consumer device 120 and merchant device 130 are arranged to communicate with one another over a network (not shown) such as the internet. The consumer device 120 is able to access a website associated with the merchant device 130 over the network in order to identify a product to be purchased. The purchasing of the product is managed by the server 1 10, which has the financial information of both the consumer and merchant stored within its memory. When the consumer wishes to purchase something from the merchant the server 1 10 is then able to securely manage the transaction such that neither the consumer nor the merchant need to share financial information. This therefore results in an increase in the level of security provided by the transaction.

The process of the consumer device 120 purchasing a product or service from the merchant device 130 shall now be described with reference to Figure 2.

The process starts with a registration process in which the consumer device 120 and the merchant device 130 register with the server 1 10. The registration process enables the server 1 10 to securely identify both parties in the transaction thereby increasing the security of the payment transaction.

At step R1 of the registration process, the consumer device 120 registers with the server 1 10. The consumer device 120 sends a request for registration to the consumer's bank. In response to the registration request, the bank sends data comprising financial details and identification details of the consumer to the server 1 10. The identification details include data comprising one or more of a hashed one-time passcode (OTP) generated by the bank and returned by the consumer to the bank as part of the registration process, the consumer's social security number, and the country code of the consumer's place of residence. The financial details of the consumer include data comprising the consumer's credit card details and/or bank account details.The bank communicates directly with the server 1 10 over a secure network such that the consumer's financial information is never transferred directly from the consumer over what is likely to be a relatively insecure network connection.

Optionally, the data may be transmitted over an IPSec protected connection or a 2-way SSL protected connection.

When received by the server, the consumer's information is stored securely in the memory of the server.

At step R2, an equivalent registration process is provided for the merchant 130 to register personal/company information which may include financial information with the server 1 10. When enrolling a new consumer the enrollment procedure ensures that the following parameters are available for both the server 1 10 and consumer 120, e.g. via the proxyPay App on the consumer's smartphone:

1. Social security number (or Company registration number, if a company rather than individual)

2. Hash value of a OTP

3. Country code

These three parameters are used to implement the dynamic user ID concept, as will be discussed in more detail below.

At step S1 of the dynamic user ID procedure, the following takes place on the consumer device 120. As soon as the consumer has entered his or her social security number and the OTP sent by the bank into the App, the app will generate a first dynamic user ID for the consumer. This may take place as the consumer enters this information into the app during the registration process, or could be input at a later date if the registration process was carried out on a different device. The dynamic user ID is then generated by:

1. Calculating a hash value (SHA-256) over the received OTP (H 1 )

2. Concatenating this hash to the social security number and calculating a new hash value over the concatenated expression (H2).

In practice, these steps work in the following way. The OTP is displayed in clear text in the online bank of the user as the result of the registration, while the bank communicates the hash of this OTP to the proxyPay central server 1 10. The OTP may be four or six digits while the hash is 64 characters.

The user reads the OTP and then types the 4 or 6 digits into his smartphone. The app will then first calculate the hash of the OTP and the concatenate the hash to the social security number and calculate the hash over the string. The result will be prefixed with the country code and this will constitute the first User ID.

The proxyPay central server receives the hashed OTP along with the social security number and financial payment information (credit card numbers, expire dates, CVC codes). It concatenates the hashed OTP to the social security number and calculates the hash over this concatenated string. The result of this hash calculation is prefixed with the country code configured into the proxyPay central server 1 10, 'UK' for instance. This value will be identical to the value calculated by the user's smartphone and will constitutes the first User ID.

H2 then constitutes the first dynamic user ID. The Dynamic user IDs will have a format like this: UKFBB3472B4B6FD20E130F42B238F01A37E6E0EE45CA7AD9E41774EDFE6E1 EA8B3

At step S2 the first Dynamic User ID is separately generated on the server 1 10 by:

1. Concatenating the hash value of the OTP to the social security number, both values were received from the consumer's bank and calculate a new hash value over the concatenated expression (H2).

H2 also constitutes the first dynamic User ID. H2 is guaranteed to be identical to the H2 calculated by the app in the consumer's smartphone.

Independent generation of the User ID by both the server 1 10 and the consumer device 120 provides an extremely secure system.

When the consumer subsequently sends information identifying himself to the server, for example in order to request a payment to be made or log into a system, the consumer identifies himself by sending H2 as the user ID.

In order to protect the server 1 10 against fraud, the server 1 10 implements a time-based mechanism where a new random 4 or 6 digits code, like a OTP, is generated for the consumer 120 and is sent by Over The Air (OTA) standard provisioning or SMS to the App in the consumer's smartphone at step S3. The time-based mechanism is configurable and may be policy based. In some arrangements, the new OTP is sent responsive to a purchase by the consumer. The consumer then sends an acknowledge message back to central server confirming the 6 digits code is received.

After the confirmation has been sent, a new dynamic user ID is calculated at the consumer device 120 using the same function as the first dynamic user ID at step S4. However, in cases other than the first time the dynamic user ID is generated the previous dynamic user ID is used in place of the consumer's social security number and the new 4 or 6 digit code is used in place of the previous OTP. In the app on the consumer device 120 the dynamic user ID is stored encrypted under a symmetric encryption key that is derived from the consumer's pin code.

When the server has generated the 4 or 6 digit code, it also updates the dynamic user ID that it has stored in its memory using the same technique at step S5. Consequently, the dynamic user ID for that consumer remains the same at both the consumer and server side.

In use, whenever the consumer wants to make a payment, the current dynamic user ID is

incorporated within the payment request, at step S6. At step S7, the server 1 10 then checks the dynamic user ID that it receives from the consumer device 120 with the dynamic user ID that it has stored in its memory for that consumer. In this arrangement, the server simply checks the received and stored dynamic user IDs are identical. If the dynamic user IDs match then permission is granted and the transaction proceeds. If the dynamic IDs do not match then permission is refused and the transaction does not proceed. It will be appreciated that these steps could also take place immediately after the first dynamic user ID is created, i.e. the first dynamic user ID could be the current dynamic user ID. In other arrangements, security can be improved by providing a later step in the transaction process in which a digital signature is calculated over the transaction where the public key used for the verification is associated with the dynamic user ID.

It will be appreciated that while the above arrangement relates to an action of a consumer purchasing a product or service from a merchant, the concept disclosed herein is significantly broader in scope. Any arrangement in which a first entity or user provides security information to a second entity or user in order for information to be exchanged would fall within the scope of this concept. For example, this approach could be used in a system wherein a user is logging into his or her online banking system. In fact, this could apply to any situation in which a user logs into any system. It could also be used for an employee to log into a work remote access system. It could be used for employees in distributed offices to log into a system and communicate with one another.

It will be appreciated that various aspects of the process provided on the system could be implemented by different components of the system. The functionality of the server 1 10 could be incorporated into, or partially implemented by, the merchant system 130, for example. Acts such as the verification of the new log in details could be performed at various different parts within the system. The server 1 10 could manage all processes as it does in the description above. In other arrangements, the server 1 10 could just generate the passcode, in other arrangements it could just authorise the action by verifying the authentication code.

In alternative arrangements, the authorisation of the authentication code is not carried out by comparing the authentication code received from the second computer system with the one stored in the first computer system.

It will be appreciated that in other implementations information other than the Social security number may be used as an input to the generation of a new authentication code. For example, a Company registration number, a personal identification number, a Country code associated with the consumer, mobile phone numbers, social network identifiers, email addresses or any other string of letters and/or numbers could be used as the initial input.

While reference is made to using the country code in the creation of the first user ID, it will be appreciated that the code could be omitted. The country code is there for solving future routing issues. Furthermore, during registration the online bank could fully generate the first User ID because the bank possesses the required parameters (social security number and OTP). The Online Bank could then generate a QR-code containing the first User ID that the user could scan into the application. This is may reduce processing and provide an improved user experience.

Another way to achieve the concept of dynamic user ID's is by having the proxyPay central server 1 10 generate a list of, for example 100, user ID's and to encrypt this list (using the public key of the user) and send it to the smartphone 120. The central server could then from time to time transmit a number between 1 and 100 that will indicate which user ID in the list there is the active one.

Mobile phone numbers, social network identifiers and email addresses could be used instead of social security numbers.

While reference is made to a 4 or 6 digit code in the above described arrangement, it will be appreciated that various other codes could be used. A passcode comprising more or less digits than 6 could be used. The passcode could include any combination of characters. The passcode could be randomly generated. The passcode could be selected from a predefined list of passcodes. It could be any reference or code.

While Figure 2 illustrates an order of steps, it will be appreciated that this is just an illustrative order. Certain steps such as steps R1 and R2 could take place in the order R2 then R1 . Many other steps could take place in other orders.

In some arrangements values are not hashed. While this reduces the amount of processing required, there is also a level of reduction in security. Hence, the use of hashing may depend upon the application and importance of security in that application.

In arrangements, the bank could calculate the first user ID (H2) directly during the registration process and send this to the proxyPay central server.

It will be appreciated that terminology such as dynamic user ID and authorisation code may be used interchangeably. In the same way, OTP and passcode may be used interchangeably.

The various methods described above may be implemented by a computer program product. The computer program product may include computer code arranged to instruct a computer to perform the functions of one or more of the various methods described above. The computer program and/or the code for performing such methods may be provided to an apparatus, such as a computer, on a computer readable medium or computer program product. The computer readable medium may be transitory or non-transitory. The computer readable medium could be, for example, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, or a propagation medium for data transmission, for example for downloading the code over the Internet. Alternatively, the computer readable medium could take the form of a physical computer readable medium such as semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disc, and an optical disk, such as a CD-ROM, CD-R/W or DVD.

An apparatus such as a computer may be configured in accordance with such code to perform one or more processes in accordance with the various methods discussed herein. Such an apparatus may take the form of a data processing system. Such a data processing system may be a distributed system. For example, such a data processing system may be distributed across a network.

Claims

Claims:

1. A method of authorising an action at a first computer system, the method comprising:

receiving a new authorisation code at the first computer system, wherein the new

authorisation code is generated from a previous authorisation code by a second computer system; authenticating the new authorisation code; and

authorising an action following successful authentication of the new authorisation code.

2. The method of claim 1 wherein the new authorisation code is sent to the first computer system by the second computer system.

3. The method of claim 1 wherein the new authorisation code is sent to the first computer system by a third computer system.

4. The method of any preceding claim, wherein the new authorisation code is generated from the previous authorisation code and an additional input.

5. The method of claim 4, wherein the new authorisation code is generated by:

concatenating the previous authorisation code to the additional input to create a concatenated expression; and

calculating a hash value over the concatenated expression, wherein the new authorization code is the resultant hash value.

6. The method of one of claims 4 or 5, wherein the additional input comprises a passcode.

7. The method of claim 6, wherein the passcode is generated by the first computer system and sent to the second computer system for generating the new authentication code.

8. The method of claim 6, wherein the passcode is received by the first computer system having been generated by a computer system other than the first computer system.

9. The method of any preceding claim, wherein the step of authenticating the new authorisation code comprises comparing the new authorisation code with an authenticating authorisation code.

10. The method of claim 9, wherein the authenticating authorisation code and the new authorisation code are generated by the first and second computer systems respectively using the same method.

1 1. The method of any preceding claim wherein the authorised action comprises a financial transaction.

12. The method of any preceding claim, further comprising sending, from the first computer system, confirmation of the authorisation of an action following successful authentication of the authorisation code.

13. The method of claim 12, wherein the first computer system authenticates the new authorisation code and sends confirmation of the authorisation of an action following successful authentication of the authorisation code to the second computer system.

14. The method of any preceding claim, further comprising:

receiving a further authorisation code at the first computer system, wherein the further authorisation code is generated from the new authorisation code by the second computer system; authenticating the further authorisation code; and

authorising an action following successful authentication of the further authorisation code.

15. The method of any preceding claim, further comprising:

receiving, prior to receiving the new authorisation code, a first authorisation code at the first computer system, wherein the first authorisation code is generated from an initialisation code by the second computer system;

authenticating the first authorisation code; and

authorising an action following successful authentication of the first authorisation code.

16. The method of claim 15, wherein the initialisation code comprises one or more of a social security number, a company registration number, a personal identification code and a location identifier such as the country code of a place of residence of a user associated with the second device.

17. A computer-readable medium comprising instructions that are executable by a processor to perform the method of any preceding claim.

18. A server comprising a memory arranged to store computer-implementable code arranged, in use, to implement the method of any one of claims 1 to 16, and a processor arranged to implement the code stored in the memory.