Methods and systems for physical communication access control

Abstract

A computing device, such as an Internet of Things (IoT) device, which comprises a service user side (SUS) and a service provider side (SPS) connected by a physical communication channel such as a seri

Description

FIELD OF THE INVENTION

[0001] The present invention relates to the field of access control, and more particularly, to access control based on service level groups. BACKGROUND OF THE INVENTION

[0002] Communication between a service provider and a service user which are physically connected by a communication line such as a serial line has potential risks where a malicious third party with physical access to the computing device can use, configure, and / or access services from the service provider without having a mechanism in place for the authorization of a legitimate user.

[0003] There is thus a need for access control in such computing devices. SUMMARY OF THE INVENTION

[0004] According to one or more embodiments, there is provided a method for access control in a computing device, the computing device comprising a service user side and a service provider side, wherein the service user side and the service provider side are connected by a physical communication channel, the method comprising: defining a first service group having a first privilege level, the first service group comprising a first set of services accessible to a user within the first privilege level; and defining a second service group having a second privilege level, the second service group comprising a second set of services accessible to a user within the second privilege level; wherein, at a time of a user requesting access to a desired service group of the first service group or the second service group, the method further comprises: connecting, by the service user side, to the service provider side, the connecting comprising providing an identifier of the desired service group; initiating, from the service user side of the computing device, a service request relating to a service of the accessible set of services for the desired service group; sending, via the physical communication channel, the service request to the service provider side of the computing device; checking, by the service provider side, the privilege level of the user; and allowing or refusing access to the requested service based on the service group and the privilege level.

[0005] According to some embodiments, the physical communication channel is a serial communication channel.

[0006] According to some embodiments, connecting to the service provider side of the computing device comprises an authentication challenge.

[0007] According to some embodiments, the service group comprises an authentication type and an authentication key, and wherein the method further comprises: signing, by the user, using the authentication key of the desired service group, the service request; and validating, by the service provider side, using the authentication key of the desired service group, the signature of the signed service request.

[0008] According to some embodiments, the service group comprises an encryption type and an encryption key, and wherein the method further comprises: encrypting, by the user, using the encryption key of the desired service group, the service request; and decrypting, by the service provider side, using the encryption key of the desired service group, the encrypted service request.

[0009] According to some embodiments, the method further comprises encrypting, by the service provider side, using the encryption key of the desired service group relating to the service request, a response to the service request and sending the encrypted response to the service user side over the physical communication channel.

[0010] According to some embodiments, at a time a user has successfully connected to the first service group, the method further comprises requesting a service of the set of services accessible for the second service group without switching to the privilege level of the second service group by: initiating a service request for the service of the second service group; signing the service request for the service of the second service group with the authentication key of the second service group; encrypting the service request for the service of the second service group with the encryption key of the second service group; signing the encrypted service request with the authentication key of the first service group; encrypting the service request with the encryption key of the first service group; and sending the service request to the service provider side.

[0011] According to some embodiments, the method further comprises, by the service provider side: decrypting the service request using the encryption key of the first service group; validating the signature of the service request using the authentication key of the first service group; decrypting the service request of the second service group using the encryption key of the second service group; validating the signature of the service request of the second service group using the authentication key of the second service group; and providing the requested service from the second service group.

[0012] According to some embodiments, communication between the service user side and the service provider side over the physical communication channel comprises attention “AT” commands.

[0013] According to some embodiments, the computing device is an internet of things “loT” device.

[0014] According to some embodiments, in the computing device, the service user side and the service provider side are located on the same circuit board.

[0015] According to one or more embodiments, there is provided a system comprising a computing device, the computing device comprising a service user side and a service provider side, wherein the service user side and the service provider side are connected by a physical communication channel, the service provider side configured to store: a predefined first service group having a first privilege level, the first service group comprising a first set of services accessible to a user within the first privilege level; and a predefined a second service group having a second privilege level, the second service group comprising a second set of services accessible to a user within the second privilege level, the service user side configured to, at a time of a user requesting access to a desired service group of the first service group or the second service group: connect to the service provider side of the computing device, the connecting comprising providing an identifier of the desired service group; initiate a service request relating to a service of the accessible set of services for the desired service group; and send, via the physical communication channel, the service request to the service provider side of the computing device; and the service provider side further configured to, in response to receiving the service request: check the privilege level of the user; and allow or refuse access to the requested service based on the service group and the privilege level.

[0016] According to some embodiments, the physical communication channel is a serial communication channel.

[0017] According to some embodiments, the service provider side is configured to issue an authentication challenge in response to the connecting.

[0018] According to some embodiments, the service group comprises an authentication type and an authentication key, and wherein the service user side is configured to sign the service request using the authentication key of the desired service group, and wherein the service provider side is configured to validate the signature of the signed service request using the authentication key of the desired service group.

[0019] According to some embodiments, the service group comprises an encryption type and an encryption key, and wherein the service user side is configured to encrypt the service request using the encryption key of the desired service group, and wherein the service provider side is configured to decrypt the encrypted service request using the encryption key of the desired service group.

[0020] According to some embodiments, the service provider side is configured to encrypt, using the encryption key of the desired service group relating to the service request, a response to the service request and to send the encrypted response to the service user side over the physical communication channel.

[0021] According to some embodiments, at a time a user has successfully connected to the first service group, the service user side is configured to request a service of the second service group without switching to the privilege level of the second service group by: initiating a service request for the service of the second service group; signing the service request for the service of the second service group with the authentication key of the second service group; encrypting the service request for the service of the second service group with the encryption key of the second service group; signing the encrypted service request with the authentication key of the first service group; encrypting the service request with the encryption key of the first service group; and sending the service request to the service provider side.

[0022] According to some embodiments, the service provider side is configured to: decrypt the service request using the encryption key of the first service group; validate the signature of the service request using the authentication key of the first service group; decrypt the service request for the service of the second service group using the encryption key of the second service group; validate the signature of the service request for the service of the second service group using the authentication key of the second service group; and provide the requested service from the second service group.

[0023] According to some embodiments, the service user side and the service provider side are configured to communicate over the physical communication channel using attention “AT” commands.

[0024] According to some embodiments, the computing device is an internet of things “IoT” device.

[0025] According to some embodiments, in the computing device, the service user side and the service provider side are located on the same circuit board.

[0026] According to one or more embodiments, there is provided a method comprising: defining a first service group of a service user side of a computing device, the first service group having a first privilege level, the first service group comprising a first set of services accessible to a user within the first privilege level; and defining a second service group of the service user side of the computing device, the second service group having a second privilege level, the second service group comprising a second set of services accessible to a user within the second privilege level; and, at a time a user has successfully connected to the first service group, requesting a service of the second set of services accessible for the second service group without switching to the privilege level of the second service group by using service group tunnelling, said service group tunnelling comprising: initiating a service request for the service of the second service group; signing the service request for the service of the second service group with an authentication key of the second service group; encrypting the service request for the service of the second service group with an encryption key of the second service group; signing the encrypted service request with an authentication key of the first service group; encrypting the service request with an encryption key of the first service group; and sending the service request to a service provider side, wherein the service user side and the service provider side are connected by a physical communication channel.

[0027] According to some embodiments, the method further comprises, by the service provider side: decrypting the service request using the encryption key of the first service group; validating the signature of the service request using the authentication key of the first service group; decrypting the service request of the second service group using the encryption key of the second service group; validating the signature of the service request of the second service group using the authentication key of the second service group; and providing the requested service from the second service group.

[0028] According to some embodiments, connecting to the first service group comprises providing an identifier of the first service group; initiating, from the service user side of the computing device, a service request relating to a service of the accessible set of services for the first service group; sending, via the physical communication channel, the service request to the service provider side of the computing device; checking, by the service provider side, the privilege level of the user; and allowing or refusing access to the requested service based on the service group and the privilege level. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] For a better understanding of embodiments of the invention and to show how the same can be carried into effect, reference will now be made, purely by way of example, to the accompanying drawings in which like numerals designate corresponding elements or sections throughout. In the accompanying drawings:

[0030] Fig. 1 is a block diagram of an exemplary computing device which may be used with embodiments of the present invention;

[0031] Fig. 2 a flowchart of a method for access control in a computing device, according to some embodiments of the invention;

[0032] Fig. 3 shows an example separation of services into service groups, according to some embodiments of the invention.

[0033] Fig. 4 shows an example processing of a service request, according to some embodiments of the invention; and

[0034] Fig. 5 is a schematic example of service request tunnelling, according to some embodiments of the invention.

[0035] It will be appreciated that, for simplicity and clarity of illustration, elements shown in the figures have not necessarily been drawn to scale. For example, the dimensions of some of the elements may be exaggerated relative to other elements for clarity. Further, where considered appropriate, reference numerals may be repeated among the figures to indicate corresponding or analogous elements. DETAILED DESCRIPTION OF THE INVENTION

[0036] In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the invention. However, it will be understood by those skilled in the art that the present invention can be practiced without these specific details. In other instances, well-known methods, procedures, and components, modules, units and / or circuits have not been described in detail so as not to obscure the invention.

[0037] Typically computing devices, particularly internet of things (loT) devices, have a service user side and a service provider side. The service user side and / or service provider side may be, for example, a microprocessor unit (MCU) or module. The service user side and service provider side may be connected by a physical communication channel (e.g. a wired connection), such as a serial communication channel (e.g. PCIe (Peripheral Component Interconnect Express), SPI (Serial Peripheral Interface) or parallel communication channel (e.g. PCI (Peripheral Component Interconnect). The service user side and service provider side may be installed on the same circuit board (such as a printed circuit board, PCB), e.g. they may be part of the same integral computing device. As such, the communication distance between the service user side and the service provider side may be small, for example on the scale of less than 1 metre.

[0038] Embodiments of the invention may provide access control on these short communication distances using, for example, signature validation and encryption, which may typically not be employed internally in a computing device due to a prejudice that attackers may not have access to the integral physical device and thus cannot tap the communication channel between service user and service provider sides within the computing device, compared to, for example, inter device communication which may be over may hundreds or thousands of metres and thus introduce greater opportunity for attackers to “tap” the communication channel. Particularly for internet of things (loT) devices which may be deployed in the field, there may be a risk that an attacker could access and exploit the physical communication channel between service user and service provider sides of the same integral computing device.

[0039] The service user side may request services from the service provider side. The nature of these services may depend on the nature of the computing device in which the modules are installed. For example, the services may be or may relate to connection manager services and / or device diagnostic services.

[0040] Connection manager services may be used to configure underlying network parameters such as channel, frequency, or the like, and the computing device may use the configured parameters to initiate connection procedures for a specified network.

[0041] Device diagnostic services may be used to obtain various debug information from the computing device, such as run time logs and / or getting trace information from previous error / crash scenario, which may help the developer to understand and debug a particular issue. Device diagnostic services may be associated with a higher privilege level service because it may not be desired that all the service user can access such information from the computing device, and thus access may be controlled by limiting to a subset of users.

[0042] Communication between the service user side and the service provider side may be based on Attention (AT) command sets (e.g. Hayes command sets), which will be known to the skilled person as a command language for modems.

[0043] Reference is now made to Fig. 1, which is a block diagram of an exemplary computing device 100 which may be used with embodiments of the present invention.

[0044] Computing device 100 may include a controller or processor 105 that may be, for example, a central processing unit processor (CPU), a chip or any suitable computing or computational device, an operating system 115, a memory 120, a storage 130, input devices 135 and output devices 140.

[0045] Operating system 115 may be or may include any code segment designed and / or configured to perform tasks involving coordination, scheduling, arbitration, supervising, controlling or otherwise managing operation of computing device 100, for example, scheduling execution of programs. Memory 120 may be or may include, for example, a Random Access Memory (RAM), a read only memory (ROM), a Dynamic RAM (DRAM), a Synchronous DRAM (SD-RAM), a double data rate (DDR) memory chip, a Flash memory, a volatile memory, a non-volatile memory, a cache memory, a buffer, a short term memory unit, a long term memory unit, or other suitable memory units or storage units. Memory 120 may be or may include a plurality of, possibly different, memory units. Memory 120 may store for example, instructions to carry out a method (e.g., code 125), and / or data such as method 200 described herein.

[0046] Executable code 125 may be any executable code, e.g., an application, a program, a process, task or script. Executable code 125 may be executed by controller 105 possibly under control of operating system 115. In some embodiments, more than one computing device 100 or components of device 100 may be used for multiple functions described herein. For the various modules and functions described herein, one or more computing devices 100 or components of computing device 100 may be used. Devices that include components similar or different to those included in computing device 100 may be used, and may be connected to a network and used as a system. One or more processor(s) 105 may be configured to carry out embodiments of the present invention by for example executing software or code. Storage 130 may be or may include, for example, a hard disk drive, a floppy disk drive, a Compact Disk (CD) drive, a CD-Recordable (CD-R) drive, a universal serial bus (USB) device or other suitable removable and / or fixed storage unit. Storage 130 may include cloud-based storage. Storage 130 may include database storage. In some embodiments, some of the components shown in Fig. I may be omitted.

[0047] Input devices 135 may be or may include a mouse, a keyboard, a touch screen or pad or any suitable input device. It will be recognized that any suitable number of input devices may be operatively connected to computing device 100 as shown by block 135. Output devices 140 may include one or more displays, speakers and / or any other suitable output devices. It will be recognized that any suitable number of output devices may be operatively connected to computing device 100 as shown by block 140. Any applicable input / output (I / O) devices may be connected to computing device 100, for example, a wired or wireless network interface card (NIC), a modem, printer or facsimile machine, a universal serial bus (USB) device or external hard drive may be included in input devices 135 and / or output devices 140.

[0048] Embodiments of the invention may include one or more article(s) (e.g., memory 120 or storage 130) such as a computer or processor non-transitory readable medium, or a computer or processor non-transitory storage medium, such as for example a memory, a disk drive, or a USB flash memory, encoding, including or storing instructions, e.g., computer-executable instructions, which, when executed by a processor or controller, carry out methods disclosed herein.

[0049] Fig. 2 is a flowchart of a method 200 for access control in a computing device, according to some embodiments of the invention. The computing device comprises a service user side, and a service provider side. The service user side and the service provider side are connected by a physical communication channel. In some embodiments, the physical communication channel is a serial communication channel (e.g. PCIe (Peripheral Component Interconnect Express), SPI (Serial Peripheral Interface). In some embodiments, the physical communication channel is a parallel communication channel (e.g. PCI (Peripheral Component Interconnect)).

[0050] The computing device may be, or may include elements of, computing device 100 shown in Fig. 1.

[0051] Method 200 may include defining a first service group (Step 210). The first service group may have a first privilege level and a first set of services accessible to a user within the first privilege level. For example, the user may be a microprocessor of the service user side, and may have permission to access services in the first privilege level. At runtime, it will be understood that the first service group may already be defined, e.g. pre-defined.

[0052] Method 200 may include defining a second service group (Step 220). The second service group may have a second privilege level and a second set of services accessible to a user within the second privilege level. The second set of services of the second service group may be distinct (e.g. all different) from the first set of services of the first service group. Some of the services in the second service group may be the same as the services in the first service group.

[0053] At runtime, it will be understood that the second service group may already be defined, e.g. pre-defined. It will also be understood that any number of service groups may be defined. For example a third, fourth, fifth, etc. service group may be defined, with respective privilege levels and sets of services.

[0054] At a time of a user requesting access to a desired service group (e.g. of the first service group or the second service group) method 200 may include connecting to the service provider side (Step 230). For example, connecting, by the service user side, to the service provider side may include providing an identifier of the desired service group. For example, if a user wishes to access services restricted to the first service group, part of the connecting includes identifying the first service group as the service group to which connection is desired.

[0055] Method 200 may include initiating a service request (Step 240). Initiating a service request, from the service user side of the computing device, may include initiating a request relating to a service (e.g. the particular desired service) of the accessible set of services for the indicated desired service group. For example, the requested service may be connection manager service, a device diagnostic service, or the like.

[0056] Method 200 may include sending the service request to the service provider side of the computing device (Step 250). Ther service request may be sent over the physical communication channel linking the service user side and the service provider side. In some embodiments, the physical communication channel is a serial communication channel. In some embodiments, the physical communication channel is a parallel communication channel.

[0057] Method 200 may include checking, by the service provider side, the privilege level of the user (Step 260). For example, the service provider side may check against a stored list of users and associated privilege levels. The list may be stored locally or externally, for example in an external database.

[0058] Method 200 may include allowing or refusing access to the requested service based on the service group and the privilege level (Step 270). For example, if the user requests a service from the second set of services, and the user also belongs to the second privilege level, the service provider side may allow the request and provide the requested service. As another example, if the user requests a service from the first set of services, but the user only belongs to the second privilege level, the service provider side may refuse the request and not provide the requested service, because the user is not permitted to access that service.

[0059] The separation of services into different service groups with associated privilege levels may allow to separate developer level services, troubleshooting services, and the like.

[0060] Fig. 3 shows an example separation of services into service groups, according to some embodiments of the invention. A first service group (Service group 1) is shown schematically and labelled 301. A second service group (Service group 2) is shown schematically and labelled 302.

[0061] Each service group may include an authentication type 310, an authentication key 315, an encryption type 320, an encryption key 325, and a privilege level 330. Each service group may also include a set of services 340.

[0062] For example as shown in Fig. 3, service group 1 may include services labelled as service I. 2, and 3, whilst service group may include services labelled as service 10, 11, and 12. These services may correspond to different services (e.g. service 1 service 11). Whilst only three services are shown for each service group, they may include fewer services or more services (e.g. as shown by ellipses), and may include a different number of services (e.g. service group 1 may contain 5 services, and service group 2 may contain 20 services).

[0063] As shown in Fig. 3, service group I may have a first authentication type, denoted schematically as Value A, whereas service group 2 may have a second authentication type, denoted schematically as Value P. The authentication types may be the same, or may be different. The authentication type may be, for example, a challenge handshake authentication protocol (CHAP).

[0064] The authentication type may be associated with an authentication key 315. As shown in Fig. 3, service group 1 may have a first authentication key, denoted schematically as Value B, whereas service group 2 may have a second authentication key, denoted schematically as Value Q. The authentication keys may be different (e.g. Value B 7^ Value Q). The authentication key may be an alpha-numeric key.

[0065] As shown in Fig. 3, service group 1 may have a first encryption type, denoted schematically as Value C, whereas service group 2 may have a second encryption type, denoted schematically as Value R. The encryption types may be the same, or may be different. The encryption type may be, for example, symmetric encryption, asymmetric encryption, public-key encryption, RSA (Rivest-Shamir-Adleman) encryption, Advanced Encryption Standard (AES), or the like.

[0066] The encryption type may be associated with an encryption key 325. As shown in Fig. 3, service group 1 may have a first encryption key, denoted schematically as Value D, whereas service group 2 may have a second encryption key type, denoted schematically as Value S. The authentication keys may be different (e.g. Value D Value S). The encryption key may be an alpha-numeric key.

[0067] As shown in Fig. 3, service group 1 may have a first privilege level denoted schematically as Value E, whereas service group 2 may have a second privilege level denoted schematically as Value T. The privilege levels are different (e.g. Value E / Value T) so as to separate services by privilege level.

[0068] Connecting to the service provider side of the computing device (e.g. as shown by Step 230 in Fig. 2) may include an authentication challenge. The authentication challenge may be based on authentication type 310 of the service group. For example, in cases where CHAP is used, the challenge may consist of a unique identifier and a random value.

[0069] Authentication (e.g. encrypted authentication) may be in place for various users intending to use the services. Users may be authenticated using the defined authentication mechanism (e.g. authentication type 310) before executing services from each service group for the given privilege level.

[0070] As described, the service user may first connect / login with the service provider by providing details such as the Group ID of the service group which the service user wants to access services from. As part of the login request, the service user may authenticate themselves using the authentication mechanism defined by the service provider for that specific service group. The service provider may configure the current service group and relevant types / keys once the authentication is successful.

[0071] For making a service request, the service user may start by preparing a service request command which may contain relevant details such as service name and various input parameters required by the service provider as part of processing the service request. Once the service request command is created, the service user may be required to attach the authentication signature to the service request which may be generated based on the authentication type and using the specific service group authentication key to which that service belongs. The signed service request command may be encrypted based on the encryption type and using the specific service group encryption key to which that service belongs.

[0072] The signed and encrypted service request may then be transferred on the physical communication channel (e.g. serial line or parallel line). Attackers eavesdropping or tapping the communication channel may be unable to interpret the service request due to data encryption. Also any modifications by attackers to the service request command may be easily detected because signature validation would result in failure.

[0073] Upon receiving the encrypted service request the service provider may decrypt it based on the currently configured group encryption type and using that group specific encryption key. Signature validation may be performed on the decrypted service request based on the currently configured group authentication type and using that group specific authentication key. Once the authentication is successful, the service provider may then start processing the service request command. The output of the request command may be subjected to the same signature and encryption process at the service provider end, and the same decryption and signature validation process at the service user end.

[0074] Fig. 4 shows an example processing 400 of a service request, according to some embodiments of the invention. As shown in Fig. 4, a service user side 410 and a service provider side 420 communicate over a physical communication channel 401, which may be a serial communication channel. In order to secure the communication channel, encrypted and authenticated message exchanges may be used for sending the input or providing service parameters from the service user as well as while sending the result from the execution of the service request by the service provider.

[0075] In step 412, the service user side may connect to the service provider side as part of a service group authentication process. Service group authentication may include an AT login command. A group ID may be provided, for example indicating the desired service group to which a desired service belongs. Step 412 may include an authentication challenge.

[0076] In Step 422 the service provider side may check the Group ID and authentication challenge and determine if the user has permission (e.g. belongs to the appropriate privilege level) of the service group corresponding to the Group ID. For example, the service provider may accept the connection request (e.g. OK), or deny the connection request.

[0077] Step 414 shows the creation of a service request. An AT command such as AT#SR1 may be used, to indicate the creation of a first service request. Parameters Pl and P2 may be included in the service request. The parameters Pl and P2 may indicate the particular service which is desired.

[0078] In Step 416 the service request may be signed. The service request may be signed using an authentication key of the service group. The signature may be an alphanumeric signature.

[0079] In Step 418 the signed service request may be encrypted. The signed service request may be encrypted using an encryption key of the service group. The encryption may be, for example, a cryptographic hash function.

[0080] The encrypted signed service request may be sent from the service user side to the service provider side over physical communication channel 401.

[0081] In Step 424 the service provider side may decrypt the encrypted signed service request. The service provider side may decrypt the encrypted signed service request using the group encryption key.

[0082] In Step 426 the service provider side may validate (e.g. check) the signature of the decrypted signed service request. For example, the signature may be validated by using the service group authentication key.

[0083] If the signature is valid, then at Step 428 the service side may process the service request. A valid signature may mean that the service user is within the privilege level of the service group which includes the services that have been requested. For example, the service provider side may allow or refuse access to the requested service based on the service group and the privilege level, e.g. the appropriate signature of the service group which only users within the associated privilege level have access to. Accordingly, if a valid signature is present, the service provider side may accept the service request (e.g. OK) and provide the requested services, for example the services corresponding to parameters Pl and P2.

[0084] A response may be sent from the service provider side to the service user side. The response may include the requested services, e.g. an output or data item relating to the requested service. The response may be signed and / or encrypted using the appropriate authentication and / or encryption keys of the service group to which the requested services belong. For example, embodiments of the invention may include encrypting, by the service provider side, using the encryption key of the desired service group relating to the service request, a response to the service request and sending the encrypted response to the service user side over the physical communication channel.

[0085] In some embodiments, after having successfully connected to the service provider side for a particular service group and privilege level, embodiments of the invention may allow to request services of a different service group (e.g. with a higher privilege level) without switching privilege level (e.g. without having to repeat Steps 412 and 422 shown in Fig. 4). The process is shown in Fig. 5, which is a schematic example of service request tunnelling, according to some embodiments of the invention.

[0086] Service request 510 contains a tunnelled service request 520. The tunnelled service request relates to services of a service group with a higher privilege level (e.g. group 2) than the group to which the service user is currently connected (e.g. group 1). Service request 520 contains the indication of the requested services (e.g. as represented by parameters QI and Q2). Service request 520 is also signed 525 (e.g. with signature 1) using the group 2 authentication key. The entire tunnelled signed service request 520 is encrypted using the group 2 encryption key.

[0087] Service request 510 includes AT command 512, e.g. AT#GRPROC relating to inserting the service request from another group within the service framework of the first group. Service request 510 also contains service request 520 “embedded” within the framework of the request. Service request 510 is signed 515 using the signature of group 1 (e.g. signature 2, being the second signature applied), for example using the group 1 authentication key.

[0088] The entire signed service request 510 (e.g. including embedded / tunnelled service request 520) is encrypted using the group 1 encryption key.

[0089] Accordingly, at a time a user has successfully connected to the first service group, embodiments of the invention may include requesting a service of the set of services accessible for the second service group without switching to the privilege level of the second service group by: initiating a service request for the service of the second service group; signing the service request for the service of the second service group with the authentication key of the second service group; encrypting the service request for the service of the second service group with the encryption key of the second service group; signing the encrypted service request with the authentication key of the first service group; encrypting the service request with the encryption key of the first service group; and sending the service request to the service provider side.

[0090] Tunnelled service requests may be constructed or structured “inside out”, e.g. the last part is encrypted using the encryption key of the service group to which the service user is already connected, with the service request for higher privilege services “inside” the outermost service request. Whilst typically only one service request may be tunnelled in this manner, many sequences or chains of service requests may be tunnelled, if necessary, e.g. a service request for a third service group may be tunnelled inside a service request for a second service group which is in turn tunnelled inside a service request for a first service group.

[0091] At the service provider side, a tunnelled service request may be “unpacked” from the “outside in,” e.g. starting by decrypting the “outermost” service request 510 which is encrypted using the group 1 encryption key, and working “inwards” to service request 520. For example, the service provider side may: decrypt the service request (e.g. service request 510) using the encryption key of the first service group; validate the signature (e.g. signature 2) of the service request using the authentication key of the first service group; decrypt the service request of the second service group (e.g. service request 520) using the encryption key of the second service group; validate the signature (e.g. signature 1) of the service request of the second service group using the authentication key of the second service group; and provide the requested service from the second service group (e.g. if validation was successful).

[0092] In some embodiments of the invention a method for service request tunnelling is provided. The method may include: defining a first service group of a service user side of a computing device, the first service group having a first privilege level, the first service group comprising a first set of services accessible to a user within the first privilege level; and defining a second service group of the service user side of the computing device, the second service group having a second privilege level, the second service group comprising a second set of services accessible to a user within the second privilege level.

[0093] At a time a user has successfully connected to the first service group, the method may include requesting a service of the second set of services accessible for the second service group without switching to the privilege level of the second service group by using service group tunnelling, said service group tunnelling comprising: initiating a service request for the service of the second service group; signing the service request for the service of the second service group with an authentication key of the second service group; encrypting the service request for the service of the second service group with an encryption key of the second service group; signing the encrypted service request with an authentication key of the first service group; encrypting the service request with an encryption key of the first service group; and sending the service request to a service provider side. The service user side and the service provider side may be connected by a physical communication channel, such as a serial communication channel. The service user side and the service provider side may be physically located on the same printed circuit board, and / or as part of the same computing device.

[0094] According to some embodiments, the method may include, for the service provider side: decrypting the service request using the encryption key of the first service group; validating the signature of the service request using the authentication key of the first service group; decrypting the service request of the second service group using the encryption key of the second service group; validating the signature of the service request of the second service group using the authentication key of the second service group; and providing the requested service from the second service group. Providing the requested service(s) may be contingent on successful validation of both signatures.

[0095] For the described tunnelling method, connecting to the first service group may include: providing an identifier (e.g. group ID) of the first service group; initiating, from the service user side of the computing device, a service request relating to a service of the accessible set of services for the first service group; sending, via the physical communication channel, the service request to the service provider side of the computing device; checking, by the service provider side, the privilege level of the user; and allowing or refusing access to the requested service based on the service group and the privilege level.

[0096] Embodiments of the invention may include a system, for example a system comprising a computing device (such as computing device 100 shown in Fig. 1). The computing device may comprise a service user side and a service provider side. The service user side and the service provider side may be connected by a physical communication channel, such as a serial communication channel or parallel communication channel. The service user side and service provider side may be located on the same circuit board, or part of the same computing device.

[0097] The service provider side may be configured to store: a predefined first service group having a first privilege level, the first service group comprising a first set of services accessible to a user within the first privilege level, and a predefined a second service group having a second privilege level, the second service group comprising a second set of services accessible to a user within the second privilege level, as described herein. More than two service groups may be defined, with respective sets of services and privilege levels.

[0098] As has been described with respect to Fig. 3, the service group may comprise an authentication type and authentication key and / or an encryption type and encryption key.

[0099] The service user side may be configured to (for example at a time of a user requesting access to a desired service group of the first service group or the second service group) connect to the service provider side of the computing device. The connecting may comprise providing an identifier of the desired service group (e.g. a group ID identifying the first or second service group). The connecting may comprise an authentication challenge from the service provider side.

[00100] The service user side may also be configured to initiate a service request relating to a service of the accessible set of services for the desired service group, and send, e.g. via the serial communication channel, the service request to the service provider side of the computing device.

[00101] The service user side may be configured to sign the service request using the authentication key of the desired service group, and encrypt the service request (e.g. encrypt the signed service request) using the encryption key of the desired service group.

[00102] The service provider side may be configured to, in response to receiving the service request: check the privilege level of the user, and allow or refuse access to the requested service based on the service group and the privilege level.

[00103] The service provider side may be configured to decrypt an encrypted service request using the encryption key of the desired service group, and to validate the signature of a signed service request using the authentication key of the desired service group.

[00104] The service provider side may be configured to encrypt, using the encryption key of the desired service group relating to the service request, a response to the service request and to send the encrypted response to the service user side over the physical communication channel. This may prevent attackers from intercepting or modifying the results of the performed service.

[00105] A system according to embodiments of the invention may be configured to perform service request tunnelling, as described herein (for example with respect to Fig. 5).

[00106] For example, at a time a user has successfully connected to the first service group, the service user side may be configured to request a service of the second service group without switching to the privilege level of the second service group by: initiating a service request for the service of the second service group; signing the service request for the service of the second service group with the authentication key of the second service group; encrypting the service request for the service of the second service group with the encryption key of the second service group; signing the encrypted service request with the authentication key of the first service group; encrypting the service request with the encryption key of the first service group; and sending the service request to the service provider side.

[00107] The service provider side may be correspondingly configured to: decrypt the service request using the encryption key of the first service group; validate the signature of the service request using the authentication key of the first service group; decrypt the service request of the second service group using the encryption key of the second service group; validate the signature of the service request of the second service group using the authentication key of the second service group; and provide the requested service from the second service group.

[00108] One skilled in the art will realize the invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. The foregoing embodiments are therefore to be considered in all respects illustrative rather than limiting of the invention described herein. Scope of the invention is thus indicated by the appended claims, rather than by the foregoing description, and all changes that come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein.

[00109] In the foregoing detailed description, numerous specific details are set forth in order to provide an understanding of the invention. However, it will be understood by those skilled in the art that the invention can be practiced without these specific details. In other instances, well-known methods, procedures, and components, modules, units and / or circuits have not been described in detail so as not to obscure the invention. Some features or elements described with respect to one embodiment can be combined with features or elements described with respect to other embodiments.

[00110] Although embodiments of the invention are not limited in this regard, discussions utilizing terms such as, for example, “processing,” “computing,” “calculating,” “determining,” “establishing”, “analysing”, “checking”, or the like, can refer to operation(s) and / or process(es) of a computer, a computing platform, a computing system, or other electronic computing device, that manipulates and / or transforms data represented as physical (e.g., electronic) quantities within the computer’s registers and / or memories into other data similarly represented as physical quantities within the computer’s registers and / or memories or other information non-transitory storage medium that can store instructions to perform operations and / or processes.

[00111] Although embodiments of the invention are not limited in this regard, the terms “plurality” and “a plurality” as used herein can include, for example, “multiple” or “two or more”. The terms “plurality” or “a plurality” can be used throughout the specification to describe two or more components, devices, elements, units, parameters, or the like. The term set when used herein can include one or more items. Unless explicitly stated, the method embodiments described herein are not constrained to a particular order or sequence. Additionally, some of the described method embodiments or elements thereof can occur or be performed simultaneously, at the same point in time, or concurrently.

Claims

1. A method for access control in a computing device, the computing device comprising a service user side and a service provider side,wherein the service user side and the service provider side are connected by a physical communication channel, the method comprising:defining a first service group having a first privilege level, the first service group comprising a first set of services accessible to a user within the first privilege level; anddefining a second service group having a second privilege level, the second service group comprising a second set of services accessible to a user within the second privilege level;wherein, at a time of a user requesting access to a desired service group of the first service group or the second service group, the method further comprises:connecting, by the service user side, to the service provider side, the connecting comprising providing an identifier of the desired service group;initiating, from the service user side of the computing device, a service request relating to a service of the accessible set of services for the desired service group;sending, via the physical communication channel, the service request to the service provider side of the computing device;checking, by the service provider side, the privilege level of the user; andallowing or refusing access to the requested service based on the service group and the privilege level.

2. The method of claim 1, wherein the physical communication channel is a serial communication channel.

3. The method of claim 1 or claim 2, wherein connecting to the service provider side of the computing device comprises an authentication challenge.

4. The method of any of claims 1-3, wherein the service group comprises an authentication type and an authentication key, and wherein the method further comprises:signing, by the user, using the authentication key of the desired service group, the service request; andvalidating, by the service provider side, using the authentication key of the desired service group, the signature of the signed service request.

5. The method of any of claims 1-4, wherein the service group comprises an encryption type and an encryption key, and wherein the method further comprises:encrypting, by the user, using the encryption key of the desired service group, the service request; anddecrypting, by the service provider side, using the encryption key of the desired service group, the encrypted service request.

6. The method of claim 5, comprising encrypting, by the service provider side, using the encryption key of the desired service group relating to the service request, a response to the service request and sending the encrypted response to the service user side over the physical communication channel.

7. The method of claim 4, and of claim 5 or 6, wherein at a time a user has successfully connected to the first service group, the method further comprises requesting a service of the set of services accessible for the second service group without switching to the privilege level of the second service group by:initiating a service request for the service of the second service group;signing the service request for the service of the second service group with the authentication key of the second service group;encrypting the service request for the service of the second service group with the encryption key of the second service group;signing the encrypted service request with the authentication key of the first service group; encrypting the service request with the encryption key of the first service group; and sending the service request to the service provider side.

8. The method of claim 7, comprising, by the service provider side:decrypting the service request using the encryption key of the first service group;validating the signature of the service request using the authentication key of the first service group;decrypting the service request of the second service group using the encryption key of the second service group;validating the signature of the service request of the second service group using the authentication key of the second service group; andproviding the requested service from the second service group.

9. The method of any of claims 1-8. wherein communication between the service user side and the service provider side over the physical communication channel comprises attention “AT” commands.

10. The method of any of claims 1-9, wherein the computing device is an internet of things “loT” device.

11. The method of any of claims 1-10, wherein in the computing device, the service user side and the service provider side are located on the same circuit board.

12. A system comprising a computing device,the computing device comprising a service user side and a service provider side, wherein the service user side and the service provider side are connected by a physical communication channel,the service provider side configured to store:a predefined first service group having a first privilege level, the first service group comprising a first set of services accessible to a user within the first privilege level; anda predefined a second service group having a second privilege level, the second service group comprising a second set of services accessible to a user within the second privilege level,the service user side configured to, at a time of a user requesting access to a desired service group of the first service group or the second service group:connect to the service provider side of the computing device, the connecting comprising providing an identifier of the desired service group;initiate a service request relating to a service of the accessible set of services for the desired service group; andsend, via the physical communication channel, the service request to the service provider side of the computing device; andthe service provider side further configured to, in response to receiving the service request: check the privilege level of the user; andallow or refuse access to the requested service based on the service group and the privilege level.

13. The system of claim 12, wherein the physical communication channel is a serial communication channel.

14. The system of claim 12 or 13, wherein the service provider side is configured to issue an authentication challenge in response to the connecting.

15. The system of any of claims 12-14, wherein the service group comprises an authentication type and an authentication key, and wherein the service user side is configured to sign the service request using the authentication key of the desired service group, and wherein the service provider side is configured to validate the signature of the signed service request using the authentication key of the desired service group.

16. The system of any of claims 12-15, wherein the service group comprises an encryption type and an encryption key, and wherein the service user side is configured to encrypt the service request using the encryption key of the desired service group, and wherein the service provider side is configured to decrypt the encrypted service request using the encryption key of the desired service group.

17. The system of claim 16, wherein the service provider side is configured to encrypt, using the encryption key of the desired service group relating to the service request, a response to the servicerequest and to send the encrypted response to the service user side over the physical communication channel.

18. The system of claim 15, and claim 16 or 17, wherein at a time a user has successfully connected to the first service group, the service user side is configured to request a service of the second service group without switching to the privilege level of the second service group by:initiating a service request for the service of the second service group;signing the service request for the service of the second service group with the authentication key of the second service group;encrypting the service request for the service of the second service group with the encryption key of the second service group;signing the encrypted service request with the authentication key of the first service group; encrypting the service request with the encryption key of the first service group; and sending the service request to the service provider side.

19. The system of claim 18, wherein the service provider side is configured to:decrypt the service request using the encryption key of the first service group;validate the signature of the service request using the authentication key of the first service group;decrypt the service request of the second service group using the encryption key of the second service group;validate the signature of the service request of the second service group using the authentication key of the second service group; andprovide the requested service from the second service group.

20. The system of any of claims 12--19, wherein the service user side and the service provider side are configured to communicate over the physical communication channel using attention “AT” commands.

21. The system of any of claims 12-20, wherein the computing device is an internet of things “loT” device.

22. The system of any of claims 12-21, wherein in the computing device, the service user side and the service provider side are located on the same circuit board.

23. A method comprising:defining a first service group of a service user side of a computing device, the first service group having a first privilege level, the first service group comprising a first set of services accessible to a user within the first privilege level; anddefining a second service group of the service user side of the computing device, the second service group having a second privilege level, the second service group comprising a second set of services accessible to a user within the second privilege level; andat a time a user has successfully connected to the first service group, requesting a service of the second set of services accessible for the second service group without switching to the privilege level of the second service group by using service group tunnelling, said service group tunnelling comprising:initiating a service request for the service of the second service group;signing the service request for the service of the second service group with an authentication key of the second service group;encrypting the service request for the service of the second service group with an encryption key of the second service group;signing the encrypted service request with an authentication key of the first service group; encrypting the service request with an encryption key of the first service group; andsending the service request to a service provider side,wherein the service user side and the service provider side are connected by a physical communication channel.

24. The method of claim 23, comprising, by the service provider side:decrypting the service request using the encryption key of the first service group;validating the signature of the service request using the authentication key of the first service group;decrypting the service request of the second service group using the encryption key of the second service group;validating the signature of the service request of the second service group using the authentication key of the second service group; andproviding the requested service from the second service group.

25. The method of claim 23 or claim 24, wherein connecting to the first service group comprises providing an identifier of the first service group;initiating, from the service user side of the computing device, a service request relating to a service of the accessible set of services for the first service group;sending, via the physical communication channel, the service request to the service provider side of the computing device;checking, by the service provider side, the privilege level of the user; andallowing or refusing access to the requested service based on the service group and the privilege level.28

Images