GB2363867A

GB2363867A - Access control method

Info

Publication number: GB2363867A
Application number: GB0014978A
Authority: GB
Inventors: Martyn Gilbert
Original assignee: Amino Holdings Ltd
Current assignee: Amino Holdings Ltd
Priority date: 2000-06-19
Filing date: 2000-06-19
Publication date: 2002-01-09
Also published as: GB0014978D0; WO2001098875A3; AU2001274245A1; WO2001098875A2

Abstract

An access control method uses an interface device 1 and a smart card 5. In operation, unencrypted data received by the interface device (e.g. a request for data or services, from a keyboard 3) is loaded onto a smart card, encrypted by the smart card and the encrypted data returned to the interface device for transmission (at 2). Encrypted data (e.g. that requested) received (at 2) by the interface device is loaded onto a smart card, decrypted by the smart card and the decrypted data returned to the interface device e.g. for display 4. The same facility can be used to confirm acceptability of software uploaded to the interface device.

Description

2363867 Access Control Method This invention relates to an access control

method using an interface device controlled by a smart card and to devices employing the method.

One known method of controlling access to information and services is to employ an interface device (IFD) together with a smart card.

In systems of this type the interface device controls access to information and requests for services and allows access to information or the sending of requests for services only if the presence of a valid smart card connected to the interface device is confirmed Typically, the smart card carries one or more digital passwords and the IFD allows access to information and the issuing of requests for services only if the correct passwords are received from the smart card.

In a different approach offering a higher level of security digital passwords or encryption/decryption keys from the smart card are actually required by the IFD in order to function For example, the issue of a password or key from the smart card may be necessary to allow the interface device to decrypt received encrypted data to be provided to a user.

In such a system the IFD itself does not know what the passwords or keys from the smart card should be but the issue of the correct password is effectively confirmed by the successful decryption of the encrypted data.

Smart cards are portable devices having on-board memory and/or processing capacity They are commonly produced in the approximate size and shape of a credit card, hence the term smart cards, but in practice can be made in any convenient shape for a particular task.

One advantage of smart card systems is that the provision of access to information and services authorised by the smart card can be separated from interface device to which the smart card is attached For example, organisations having a computer network may allow access through terminals provided with interface devices which are physically accessible to all personnel, with the degree of access to information held on the system and authority to issue instructions through the system being controlled by smart cards issued to individuals which must be inserted into IFD's associated with the terminals Also, hardware including the IFD to allow access to information provided by an information provider on a subscription basis may be too expensive and bulky for regular replacement of the IFD's to prevent unauthorised access by lapsed subscribers to be practical In such systems the issue and periodic replacement of time limited smart cards to individual subscribers or the periodic issue and replacement of smart cards to all subscribers is practical because of the low cost and small size of the smart cards.

A problem with known systems is that the passwords or encryption/decryption keys provided by a smart card can be read, copied and provided to other IFD's to allow unauthorised access to information or services The present invention is intended to overcome this problem, at least in part.

In a first aspect, this invention provides a method of controlling access using an interface device and a smart card, in which: encrypted data received by the interface device is loaded onto the smart card, decrypted by the smart card and the decrypted data returned to the interface device; and unencrypted data received by the interface device is loaded onto a smart card, encrypted by the smart card and the encrypted data returned to the interface device.

In a second aspect, this invention provides an interface device suitable for carrying out the method.

In this description references to data being unencrypted should be understood only as meaning that the level of encryption handled by the smart card has been decrypted or not yet applied It is of course possible that this -funencrypted" data has had another level or encryption applied to it elsewhere.

The invention will now be described by way of example only with reference to the accompanying diagrammatic Figures, in which:

Figure 1 shows a system arranged to employ the invention; and Figure 2 shows a system arranged to validate received software according to the invention.

In the present invention an interface device 1 can be connected to a system through a communications path 2 A user input device 3 such as a keypad is connected to the interface device 1 in order to allow the user to make request for information to the IFD 1 A display device 4 is also connected to the IFD 1 to display information provided by the IFD 1.

The IFD 1 is provided with physical and electrical connections to allow a smart card 5 to be connected to and powered from the IFD 1 Such physical and electrical connections are themselves well known and need not be described in detail herein.

The key difference between the system of the present invention and known systems is that the encryption and decryption is carried internally within the smart card 5 itself rather than being carried out by the IFD 1 using encryption keys issued by the smart card 5.

For example, where a request for services is made by the user, the logical data path 4 followed by the request is shown by the dashed line 6 in Figure 1.

The request, which may be a request for access to information or a request for services be provided, is generated by the user using the keyboard 3 This request is sent to the IFD 1 which sends it on to the smart card 5 The request is encrypted by an encryption/decryption element 7 of the smart card 5 and the encrypted request returned to the IFD 1 The IFD 1 then sends the encrypted request to another part of the system or to a separate informational service provider along the communications link 2.

The reverse process is carried out when information is provided to the user, again from another part of host system or from a separate external information provider and the logical data path is shown by the dashed line 8 in Figure 1.

The encrypted information is received by the IFD 1 along the communications link 2 and the encrypted information is supplied to the smart card 5 The encryption/decryption element 7 of the smart card 5 then decrypts the received information and passes the decrypted information back to the IFD 1 The decrypted information is then supplied to the display 4 and displayed to the user.

Thus, using the system of the invention, the IFD 1 cannot display received information or send requests for information or services without a smart card 5 being present Further, because the actual encryption and decryption is carried out by the smart card 5, it is not possible to break the security of the system by reading passwords provided by one smart card and providing these passwords to other IFD's 1.

A further advantage of the invention is that the security or quality of the encryption employed by the system can be altered as required simply by replacing the smart card 5.

The IFD 1 only has to transfer encrypted and decrypted data to and from the smart card 5 and does not carry out any encryption or decryption itself and accordingly no changes to the IFD 1 are needed when the encryption level of the smart card 5 is changed.

It should be understood that the dashed lines 6 and 8 show logical data paths only Although the physical path followed by the data will be similar, it need not be identical For example, there may a single set of connections carrying all data input to and from the smart card 5.

In many applications it is desirable for the software within the IFD 1 to be alterable or updateable by the information service provider providing the IFD and smart card Such alterations or updating of the IFD software can be carried out by uploading software from the information service provider along the communications link 2.

The problem with allowing amendment or updating of the IFD software by uploading is the risk that the IFD software could be subject to unauthorised alterations, either to alter the IFD programming to allow it be used to make cryptographic attack on the smart card or to simply delete or alter the IFD software to disable the IFD In the first case, it is of course possible that the user themselves may attempt to reprogramme the IFD to allow cryptographic attack on the smart card.

Accordingly, it is important that any software to be loaded into the IFD is validated to ensure that it is authorised software before the software replaces existing IFD software and is used.

When using the present invention, this validation process can be carried out by the smart card 5.

The new software to be loaded into the IFD 1 is uploaded along the communications link 2 together with an encrypted digest signed with a private key of the agency authorised to alter the IFD 1 software The smart card 5 contains the agency's certificate which includes the agency's public encryption key.

The digest of the purported software which has been uploaded is calculated and compared with the decrypted version of the encrypted digest enclosed with the software Only if the calculated and decrypted digests agree is the upload regarded as authorised and incorporated into the software of the IFD 1.

The term incorporated is used because the uploaded software could be intended to be added to existing software or to replace it or both.

The digest of the uploaded software could be calculated by the IFD 1 or the smart card 5 and both options will now be described with reference to Figure 2.

In both methods the purported new software is uploaded along communications link 2 into the IFD 1 and is stored in an IFD memory 9.

In the first method, the IFD 1 then calculates the digest of the uploaded software held in the memory 9 and sends the digest result to the smart card 5 together with the encrypted digest which was downloaded together with the software.

The smart card 5 then uses a public encryption key of the software issuing agency held in a memory 10 of the smart card to decrypt the encrypted digest Smart card 5 then compares the calculated digest and decrypted digest and if they are the same the smart card 5 confirms to the IFD 1 that the uploaded software is acceptable.

If the smart card 5 confirms that the uploaded software is acceptable the software is incorporated into the IFD 1 operating software as appropriate If the smart card 5 does not confirm that the uploaded software is acceptable, it is rejected and some alert notifying that an attempt to make authorised alterations to the IFD 1 software has occurrd may be carried out.

In the second method, the IFD 1 passes the purported uploaded software held in memory 9 to the smart card 5 together with the encrypted digest which accompanied the upload The smart card 5 then calculates the digest of the uploaded software and compares this with the encrypted digest which is decrypted using the public key held in the memory 10 If the calculated and decrypted digests agree, the smart card 5 confirms the IFD 1 the software is acceptable The IFD 1 then responds to the confirmation or lack of confirmation as above.

In both methods security is maintained because the decrypted version of the uploaded encrypted digest exists within the smart card 5 only and is not transmitted to the IFD 1.

The above description is intended as a simple example only and it will be understood that many other things could be connected to the IFD 1 In particular, the user input device 3 instead of being a keyboard could itself be a computer system or device issuing requests for information services to the IFD 1 when used by user or automatically Similarly, the display device 4 could be a conventional VDU or could be a more complex system to which data is provided.

One example of such a system could be where the IFD was incorporated into a television set top box and in this case the requests for information would be requests for particular programs and would be generated by the television in response to user requests and the received information would be encrypted program data which would be displayed on the TV screen after decryption.

The smart card 5 has been illustrated as containing an encryption/decryption element 7 and in Figure 2 as including a memory 10 to retain public encryption keys It should be understood that these illustrations are only intended to aid in understanding the invention and do not imply any particular physical arrangement for the smart card 5 In practice, the encryption and decryption function of the smart card 5 could be provided by a number of separate elements which may include one or more memory elements even if the software validation method described with reference Figure 2 is not to be used.

In the present application the term smart card is used for clarity because this term is commonly used to refer to devices having onboard processing capacity and/or memory.

However, this should not be regarded as implying any particular physical form for the smart card 5.

It is expected that the most common and convenient method of connecting the smart card 5 to the IFD 1 to allow data and power transfer will be conductive contact However, the invention is applicable to other forms of data and power transfer.

This description is given by way of example only and the skilled person will understand that the invention could be carried out in other ways.

Claims

1 An access control method using an interface device and a smart card, in which: encrypted data received by the interface device is loaded onto the smart card, decrypted by the smart card and the decrypted data returned to the interface device; and unencrypted data received by the interface device is loaded onto a smart card, encrypted by the smart card and the encrypted data returned to the interface device.

2 The method of claim 1, in which the encryption and decryption are carried out by the same smart card.

3 The method of claim 1 or claim 2, in which the encrypted or decrypted data returned to the interface device by the smart card is then sent to another device by the interface device.

4 The method of any preceding claim, in which the interface device sends the decrypted data to a display device.

The method of any preceding claim, in which the unencrypted data received by the interface device is user input.

6 An interface device and smart card substantially as shown in or as described with reference to the accompanying figures.

6 The method of claim 5, in which the user input includes requests for encrypted data to be sent to the interface device.

7 The method of any preceding claim, in which the interface device receives software to be executed by the interface device together with encrypted data including an encrypted digest of the software and the software is validated by the steps of:

calculating a digest of the received software; loading the encrypted digest onto the smart card; decrypting the encrypted digest on the smart card; and comparing the calculated digest and the decrypted digest on the smart card.

8 The method of claim 7, in which the calculated digest is calculated by the interface device and loaded onto the smart card.

9 The method of claim 7, in which the software is loaded onto the smart card and the calculated digest calculated on the smart card.

The method of any of claims 7 to 9, in which the encrypted digest is signed with a private encryption key of an authorised software supplier and the suppliers public encryption key is stored in the smart card.

11 An interface device suitable for carrying out the method of any preceding claim.

12 An interface device and smart card substantially as shown in or as described with reference to the accompanying figures.

Amendments to the claims have been filed as follows 1 A validation method using an interface device and a smart card, in which software to be executed by the interface device together with encrypted data including an encrypted digest of the software is received by the interface device; a digest of the received software is calculated; the encrypted digest is loaded onto the smart card; the encrypted digest is decrypted by the smart card; and the calculated digest and the decrypted digest are compared by the smart card in order to validate the received software.

2 The method of claim 1, in which the calculated digest is calculated by the interface device and loaded onto the smart card.

3 The method of claim 1, in which the software is loaded onto the smart card and the digest is calculated on the smart card.

4 The method of any of claims 1 to 3, in which the encrypted digest is signed with a private encryption key of an authorised software supplier and the suppliers public encryption key is stored in the smart card.

An interface device comprising smart card interface means able to communicate with a smart card and communications means; the device is suitable for receiving software and an encrypted digest thereof by the communications means, passing the encrypted digest in encrypted form to a smart card by the interface means and executing the software only after a validation signal generated by the method of any preceding claim is received by the interface means from the smart card.