EP3031036A2 - Access and control authorisation system - Google Patents
Access and control authorisation systemInfo
- Publication number
- EP3031036A2 EP3031036A2 EP14762052.0A EP14762052A EP3031036A2 EP 3031036 A2 EP3031036 A2 EP 3031036A2 EP 14762052 A EP14762052 A EP 14762052A EP 3031036 A2 EP3031036 A2 EP 3031036A2
- Authority
- EP
- European Patent Office
- Prior art keywords
- user
- access
- authenticator
- privilege
- access device
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Ceased
Links
Classifications
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
- G07C9/00—Individual registration on entry or exit
- G07C9/20—Individual registration on entry or exit involving the use of a pass
- G07C9/27—Individual registration on entry or exit involving the use of a pass with central registration
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
- G07C9/00—Individual registration on entry or exit
- G07C9/00174—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys
- G07C9/00309—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys operated with bidirectional data transmission between data carrier and locks
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
- G07C9/00—Individual registration on entry or exit
- G07C9/30—Individual registration on entry or exit not involving the use of a pass
- G07C9/38—Individual registration on entry or exit not involving the use of a pass with central registration
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
- G07C9/00—Individual registration on entry or exit
- G07C9/30—Individual registration on entry or exit not involving the use of a pass
- G07C9/32—Individual registration on entry or exit not involving the use of a pass in combination with an identity check
- G07C9/37—Individual registration on entry or exit not involving the use of a pass in combination with an identity check using biometric data, e.g. fingerprints, iris scans or voice recognition
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
- G07C9/00—Individual registration on entry or exit
- G07C9/20—Individual registration on entry or exit involving the use of a pass
- G07C9/22—Individual registration on entry or exit involving the use of a pass in combination with an identity check of the pass holder
- G07C9/25—Individual registration on entry or exit involving the use of a pass in combination with an identity check of the pass holder using biometric data, e.g. fingerprints, iris scans or voice recognition
- G07C9/257—Individual registration on entry or exit involving the use of a pass in combination with an identity check of the pass holder using biometric data, e.g. fingerprints, iris scans or voice recognition electronically
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1441—Countermeasures against malicious traffic
- H04L63/1466—Active attacks involving interception, injection, modification, spoofing of data unit addresses, e.g. hijacking, packet injection or TCP sequence number attacks
Definitions
- This invention relates to an access and control authorisation system.
- a vehicle or indeed other asset
- a device carried by the user that is not permanently linked to the vehicle or other asset, for example a smart phone, mobile telephone or cell phone, with use rights being transmit- ted centrally to the user's device and to the vehicle or asset so that the vehicle or asset can recognise the user's device as granting access or other rights when in communication there with.
- use rights being transmit- ted centrally to the user's device and to the vehicle or asset so that the vehicle or asset can recognise the user's device as granting access or other rights when in communication there with.
- US2009/018541 A1 discloses triangular communication to authenticate the user via his mobile phone and to grant access to a master locking device.
- an access authorisation system comprising a central authenticator and an access device controlling access to each of a plurality of resources, the access device being remote from the central authenticator and being programmable and configured to communicate therewith, wherein the authenticator stores:
- an access device identifier for each of a plurality of access devices, an access device identifier and data relating to each of the resources controlled by the access device;
- the authenticator in response to receipt of the request, the authenticator re-quests the user to provide to the authenticator individual identifying data for the user;
- the authenticator compares the sent data with stored data to verify the user's identity; (c) the authenticator transmits to the access device instructions to allow the user to exercise the or each privilege.
- the user may be a person or an inanimate object having some form of processing and communication capacity.
- the au- thenticator is preferably programmed in step (a) to request the user to provide personal identifying data, which can comprise one or more of a personal identification number and unique physical characteristics of the user.
- the unique physical characteristics may include a fingerprint, a retina pattern, a face image or part thereof, and a speech sample, but are not limited to these, and can be anything which uniquely identifies an individual.
- the system further comprises a user device remote from the central authenticator and programmable and configured to communicate with the access device and with the central authenticator, wherein the user device, the authenticator and the access device are programmed to perform the following steps in response to the user causing the user device to request from the authenticator exercise of the privilege:
- the authenticator instructs the user device to display to the user a request to input personal identity data
- the user device transmits the personal identity data input by the user to the authenticator and the authenticator compares this with stored data to verify the user's identity;
- the authenticator transmits a transaction token to the access device and to the user device;
- the user device communicates with the access device to request exercise of the privilege, the communication including the user device transaction token;
- Another aspect of the invention provides a secure communication system between a verification device and a remote device, wherein the remote device comprises:
- processing means having an operating system for controlling the basic operation of the remote device and a container program installed thereon to function under the operating system,
- the verification device comprises:
- processing means programmed to communicate with the container program in the remote device to install on the remote device in response to receipt of a communication request from the remote device a temporary virtual machine controlling communication with the verification device independently of the operating system of the remote device;
- the container program is configured to uninstall the virtual machine from the remote device in response to an instruction from the verification device via the virtual machine.
- the remote device may be the user's mobile telephone, and it will be appreciated that verification of the user can involve any of the features of a so- called smart phone, for example the use of a touchscreen, camera or microphone, or any combination of these.
- a camera permits the application of close proximity gestures instead of, or as well as, the touchscreen.
- Oth- er communication devices for example wearable devices, may be used, paired with, or independently of, a smart phone.
- the invention also provides a secure data communications system, comprising first and second programmable devices configured to communicate with each other and with a remote server device configured to issue at intervals to the first device and the second device an encrypted security code, the system further being configured such that, when any of the devices initiates communication with any of the other devices by transmission of its security code, the receiving device compares the received code with the most recent security code received from the server and only allows communication to continue if the conformity between the codes and their transmission criteria is within predetermined limits.
- the Platform is a multi-tiered "wholesale" architecture allowing diminishing grant of authority and administration.
- the prime function is to deploy white label sub instances that can be separately branded upon which a customer bespoke market can be created with the SDKs and APIs provided.
- the software system does not create an installed application onto a portable device but instead delivers a facsimile of a mobile application within a secure container.
- the system leaves no residual transactional data on the portable device, other than that which is required for facilitation of the visuals of an application once the app is closed or a specific function has been achieved.
- the content off the applications is based on composite elements of services and functionality borne from The Platform. Any standard industry security technology can be applied to the transmission path between the platform and the display within the connected handheld device.
- the system also allows control and effect of hardware and API elements within the internet device, for example the ability to enable GPS, Bluetooth, and a camera function.
- the system is however not a "web app" as access is through a proprietary software container rather than the generic device web browser.
- This object (software or software within a device) controls a physical locking mechanism and capability to allow access to connected downstream subsystems.
- This ele- ment may be represented by either a black box containing a controller chip with an embedded operating system (Java, Android etc.) or expressed as an application the function of which can function on a number of open standard embedded operating systems.
- the functions of this software are - a) To provide a receptacle for the Secure Mobile Engine, b) As agent software in which to deploy secure data via the mobile application fabric from within the platform.
- firewall and single point of ingress for external data communication to subsystems I VI, critical safety systems, telematics data and functional system data (e.g., engine warning lights).
- the Gateway Application operates in two modes: Online, where there is access to external internet based services via public wireless networks via the host iteration of The Platform; and an Offline mode, where a perpetuating recursive logic system maintains vehicle system and subsystem security as well as condition grant of access and use for validated and authorized drivers or those requiring access to the vehicle and sequential validated access to sub systems and functions.
- An additional function of the gateway is to provide an authenticated identity information path back through The Platform to off board web services (Twitter, Facebook etc.) and in doing so provides a "Single Sign On” facility for providing inbound web services or elements of web services into the higher functions of the car (e.g., the IVI or "head unit” display and its operating system). This allows prevention of the current issue of remnant services being re- tained in the vehicle (such as Satnav history, telephone records etc.), as each authenticated driver would see only their personal information rather than that of the previous driver/s.
- Advantages of various aspects of the invention include: i. Providing irrefutable proof of identity of a person wishing to access an object and control elements within that object in context to their identity and their privileges in context to that system in real-time taking theoretically a limitless number of external contributing factors to that permission being granted.
- ii The ability to identify uniquely all occupants of a vehicle or building and potentially retains records of that entry scenario and context.
- iii Disambiguating the notion of a lock and key, or key token with the metaphorical "unlocking" process being abreacted to The Platform or proactive decision making by elements granted into the asset end point. This makes theft or fraudulent entry to the system protected significantly reduced if not negated.
- the control software in the vehicle would have based upon rules the possibility to render the car inoperable once the engine had been turned off etc.
- E- Call is a European wide automotive automatic call to emergency services in the event of an accident. This call is proceeded by a telematics data burst of location and other vehicle attributed to the emergency services. With our system in place, there is the capability to continue to send location and situational data (many mobile networks will not allow simultaneous voice and data connections).
- the invention therefore further provides a system installed in a vehicle comprising means for detecting vehicle criteria indicating the occurrence of an accident, secure transmission means for transmitting to a central controller remote from said vehicle in response to detection of said criteria data identifying at least one or more occupants of the vehicle.
- the vehicle includes vital signs detection means for detecting indications that one or more of the oc- cupants is alive, for example detecting sounds, CO2 measurements indicating breathing, heartbeat monitor and eye movement monitor.
- the central controller may be configured to communicate relevant data to emergency services.
- the system is preferably associated with an E-Call or comparable installation in the vehicle, but capable of communicating independently of this.
- Figure 1 is a diagrammatic representation of a first embodiment of the in- vention
- Figure 2 illustrates the capability to create subordinate users and privileges relates thereto
- Figure 3 illustrates the use with the system of the first embodiment of a reprogrammable trust token
- Figure 4 illustrates another physical method of asserting an identity in relation to requesting or enacting a privilege
- Figure 5 is a hierarchy model illustrating a possible application of the system of the invention to a typical automotive case use
- FIG. 6 is diagrammatic representation of an alternative embodiment of the invention.
- Figures 7 to 10 illustrate an example of the alternative embodiment, applied to controlling access and use of a motor vehicle.
- FIG. 1 provides a topographical logical system overview.
- Identity 1 represents the irrefutable capture and encoding of an individual for use within the system. This may be captured using any relevant technology and will incorporate at least one biometric imprint encoded into the Identity 1 cryptographic file.
- 1 a relates to a system control module or "SAM" Security Access Module (software or hardware implementation) that is contained within a tangible and physical asset. In an automotive context, this asset would be a car or vehicle. Contained within the capabilities of that asset is 2n, a manifesto of all software and hardware capabilities requiring privilege grant that can be enacted and controlled by the overall system. 2n is synchronised between internal privilege capabilities and the providers and controllers of these privileges that exist externally to the physical asset.
- SAM System control module
- 2n a manifesto of all software and hardware capabilities requiring privilege grant that can be enacted and controlled by the overall system. 2n is synchronised between internal privilege capabilities and the providers and controllers of these privileges that exist externally to the physical asset.
- An individual will be required to have a relationship, contract, license or rights of use with an external Privilege Provider in order to activate a specific privilege function within an asset.
- an individual may have purchased the right to additional performance functions of a vehicle (e.g., higher engine power mapping and enhanced suspension damping) or access to specific software service available within the vehicle. These functions are controlled and provided externally to the vehicle.
- the ID Control Module operates in a connected, semi connected / autonomous or autonomous manner. Since encrypted privileges strings relating to a User Identity and associated Privileges are optionally stored resi- dent within the SAM memory, the SAM can, based upon simple rules algorithms grant control of Privilege functions without the requirement of communicating directly with the Platform. Depending upon the environmental and contextual nature of the request, and based upon the rules model agreed between the SAM and the Platform, the SAM can grant conditional, temporary or limited grant of privilege without the requirement to verify the action from the Platform or from Privilege Providers. This for example would be deployed in a scenario where the SAM and asset do not have sufficient access to communication technologies to verify the validity of a request to enact a privilege.
- 1 b is a SOA based service platform comprised of "off the shelf” middleware components. Its prime function is to offer "laaS" - Identity as a Service and "CaaS" - Context as a Service.
- an individual may have the privilege of unlocking the doors, entering the vehicle and starting the engine.
- 1 b is the primary management and verification system that links the disparate elements to create the context of a valid and authenticated usage of a privilege.
- the ID Control Module has the capability to autonomously take rules engine based decisions on temporary granting of privilege rights in a scenario where communications are not available for end to end messaging and verification between required entities or databases.
- Access relates to the access of control of mechanical or digital and "connected" functions or services contained within the subject asset of the system. For example, this can mean to both unlock, but also lock and place a lock in a conditional state whereby the requirements and context for operation is defined by Identity 1 , subordinate users, Identity n or is subject to the real time controls available to off-board Privilege Providers.
- Figure 2 illustrates the capability for Identity 1 or the prime controller or user to create subordinate users. These users Privileges will be confined to within those of Identity 1 but also in relation to privileges available to Identity n based upon the privileges to which they have right to via Privilege Providers. Identity 1 also has the ability to create and federate sub-privileges and condition of privilege enactment to Identity n. This is further illustrated by the sample hierarchy model described in Figure 5 that is a sample model to cover a generic Automotive Hierarchy and Privilege management use case.
- the system would allow the implementation of a reprogrammable trust token, possibly referred to as a "smart key" to act as a physical rep- resentation of a User's ability to enact privileges.
- the privilege and rights programmed into this device would be granted and controlled by both Identity 1 but also on the basis of the relationship in dynamic contextual real time that Identity n has with Identity 1 and the functions granted in relation to any Privilege Pro- viders from which Identity 1 or Identity n procures a Privilege service from.
- Identity 1 could create an asset usage profile and embody that within a Trust Token that would be physically held by an assigned Identity n or multiple Identity ns.
- Each token would grant privileges specific to that Identity or individual. If Identity n attempts to illicitly enact a privilege outside of terms of that privi- privilege grant, logic and rules within the Platform and ID Control Module (SAM) would reject the attempt.
- SAM Platform and ID Control Module
- An example could be that Identity n has controlled access to an Asset only during business hours. An attempt to access certain Privilege functions outside of business hours would be rejected. In an Automotive context, this could relate to a commercial vehicle where the User / Identity n on- ly has a contract to drive the vehicle during business hours and access relates to his specific Trust Token.
- Identity 1 can however conditionally and / or temporarily override or redefine that specific Identity n's Trust Token or apply rules of contextual conditionality as required.
- Figure 4 illustrates the physical method of asserting an Identity in re- lation to requesting or enacting grant of a privilege can be delivered in multiple ways.
- An obvious method would be the use of a Smart Phone or similar Internet Enable Device. This device could be utilised as a tool to enter an authentication request be it, alpha numeric, Biometric, gesture based or combinatorial. The precise method or requirement would depend upon the device being used as well as the ad hoc contextual requirements demanded from the Platform, the requirements of the Privilege Providers or indeed the in asset SAM.
- Figure 5 is a hierarchy model denoting a possible process of precedence in a typical automotive use case for the system. It takes into account the technical prioritisation of control of the system elements as well as the commercial/financial ecosystem in the entire usage cycle of a typical vehicle whether privately owned, leased, daily rental or pool car. As such is an archetype model to map or accommodate all users within the majority of scenarios.
- the overall objective of the system of this embodiment is to provide a secure identity and access management solution that can be employed to provide a mobile user with access to a resource or an asset based upon a range of externalized privileges. Whilst the intention is that the solution should be usable to support a range of possible applications, the sample application defined in this document is based around a vehicular system and ecosystem.
- the fundamental principle is that a irrefutably identified User Identity should be able to gain authenticated access to a resource, in such a way that the privileges associated with the User should be exposed to the resource to permit access control decisions.
- This specific requirement it corresponds to most common access control systems.
- the intention is that there be loose coupling between the components, such that the resource manager does not require pre-knowledge of either the User or the privileges granted to the User.
- the prime User or asset controller has the ability to create subordinate or even orphan users with their own access and privilege ecosystem in respect of access and usage rights to the asset in question.
- the principle concept applied is the same as that associated with the Capability-Based security model, which in turn is a standard model for secure computing.
- the proposed design is an extension of the Capability-Based model to support a distributed computing architecture.
- the role of the platform is to act as a trusted third party. It is used to register the identity of Users and SAMs - issuing them with identity credentials to support mutual identification. The platform also grants privileges to Users and provides this information to the App.
- the nomenclature applied to this, in this context is "laaS" being Identity as a Service and "CaaS" being Context as a Service.
- the Platform is a generic Service Platform comprised of "off the shelf” databases, middleware and software but built and configured to deliver and manage the relationships and functions specific to this model.
- SAM Smart Access Module
- the SAM manages access to resources. It is able to authenticate its identity (using a credential issued by the platform) and mediate access to the resource using privilege information presented by the App (on behalf of the user), or other methods utilised to authenticate a Privilege assertion on or within the functions of the Asset. These other methods may include asset onboard bi- ometric assertion and verification, alpha numeric ID assertion or a reprogram- mable physical token of access such as smart card, key or object.
- the App is a mobile device application. It provides a user interface to allow interaction between the User and Platform, as well as the User and SAM.
- the App also acts as a repository for User identity credentials and privilege in- formation (issued by the Platform).
- the App can also be used to provide subor- dinate privilege to additional users or to modify or acquire privileges held by an authenticated User Identity.
- an example asset would be a vehicle.
- a privilege would be the right to unlock the doors or further to enable or disable any possible function within that vehicle depending upon the privilege rights of the identified user.
- Such functions could include but are not limited to physical security, selective physical security, activating the ignition, starting the engine, engaging gear, releasing the handbrake, the performance characteristics of the vehicle, access to physical functions available within the vehicle such as suspension settings, access to "sport" or other modes, access to content and functions of the In Vehicle Infotainment and Navigation systems or content and applications provided by ex- ternal 3rd parties to which the identified User has an external privilege to access.
- Assets or Resources would be enrolled additionally as Identities in their own right. As such, an asset or resource would be able to access or control other resources or assets based upon its privileges within the architecture, thus allowing both instructed and automated interaction with other assets or devices.
- the SAM does not require pre-knowledge of the identity of users or their privileges.
- a SAM may be a physical element comprising electronic communication equipment, memory, a CPU and I/O capabilities to enact its function or it may be reference software that exists within a piece of specific hardware designed to enact its functions within a specific environment or asset.
- the Platform provides identity and privilege credentials to SAMs and Users, such that these may be used to create mutual trust (authentication) between SAMs and Users or indeed Users assigned subordinate Users.
- the Platform grants to the User one or more privileges that may be associated with one or more SAMs, or resources controlled by a SAM but directed via an external Privilege Provider.
- the privileges may be time limited (requiring renewal).
- the privileges associated with a User may change over time or be dictated in real time by the external Privilege Provider
- the App manages a User's credential and privileges, making them available to the SAM or Platform depending on the context.
- a User may also directly manage credentials via the platform utilizing any other suitable device or sys- tern, including the functions and capabilities of the asset itself directly via the Platform.
- Credentials to identify a User/SAM must be protected from for- gery. Credentials to identify a User/SAM must be protected from modification.
- the App function is intended to operate on any capable mobile device, such as a smart phone or tablet computer, token of privilege assertion or within the sensor capabilities of the Asset itself. These devices are outside the control of the system and could be suborned to either attack the App directly (e.g., by attempting to attack the User Credentials or privileges under the control of the App), or by using the App as a vector to attack a SAM or the Platform.
- the App must be protected from attacks on its confidentiality, integrity and availability. The degree of reliance placed on the underlying platform by the App must be minimised to protect the confidentiality, integrity and availability of interactions between the User and the App. Communication between the App and the SAM must be protected against attacks on the confidentiality and integrity of the communications channel and its content.
- the SAM (and by extension the resources it manages) must be protected from attacks. These may come from the environment in which it is located (e.g., a SAM in a vehicle must be protected from CANBUS attacks as well as attacks on its physical form) or from the external communications channel or technology to the App or Platform.
- the SAM must be protected from attacks on its confidentiality, integrity and availability that derive from its external communications and from attacks that derive from its environment.
- Cryptography will be used to meet many of the security requirements.
- Symmetric cryptography could be used to implement an access control framework suitable for distributed systems, for example Kerberos V is an implementation of an underlying mechanism defined by Needham and Schroeder that is widely used (e.g., it is the basis of the Microsoft Windows network security protocols).
- Kerberos requires a relatively tight coupling between the Us- ers, Services and the Ticket Granting and Key Distribution servers; it requires a central repository of symmetric keys that will not scale well.
- Asymmetric (public key) cryptography supports a loosely-coupled model that scales well.
- PLC public key certificate
- a Certification Authority - CA a Certification Authority
- Ephemeral trust relationships can be created between participants by exchange of X.509 certificates (and proving control of private keys) without reference to the CA - however, it should be noted that the CA may be a source of revocation information and therefore it may not be completely de-coupled.
- a PKC and AC The relationship between a PKC and AC is often compared to that of a passport and a visa; a passport is a relatively long-lived statement of identity, whereas a visa is a relatively short-lived permission to enter a specific country for a fixed period of time and is normally issued by a different authority than the passport.
- a person may have a single passport containing many visas, all or some of which may be valid concurrently.
- PKI Public Key Infrastructure
- PMI Privilege Management Infrastructure
- Asymmetric algorithms are designed such that knowledge of a public key does not allow the associated private key to be determined; the binding of a public key to a particular identity is the basis of any authentication scheme using the technology. The creation of that binding and its protection against modi- fication attacks is critical; similarly, guarding against the creation of fraudulent bindings:
- a Subject's identity and possession of a private key must be established with certainty prior to binding the identity and associated public key within an X.509 public key certificate.
- Authentication schemes based on X.509 PKC and asymmetric cryptography are reliant on trust in the CA that issued the PKC - this is termed the Trust Anchor (TA) and consists of the public key of the CA (or superior CA in a hierarchy). Typical attacks aim to substitute the TA with a forgery.
- TA Trust Anchor
- Distribution of TA values must be conducted in a manner that protects the TA value from attacks on its integrity and availability.
- Distribution of TA values must be conducted in a manner that guards against substitution of the values.
- Attribute certificates are nominally the same as public key certificates - they are both signed objects containing information - the difference is in the content. The major risks associated with AC are that they could be modified; they could be fraudulently bound to an incorrect PKC: [0059] Ownership of a public key certificate must be established before incorporating a reference to that certificate in any attribute certificate.
- TLS Transport Layer Security
- Any network protocol may be subject to three common attacks: Eavesdropping allows the confidentiality of the information to be compromised; masquerade allows an attacker to substitute his own identity for that of the trusted party; modification allows an attacker to substitute valid data for invalid data:
- the sample application selected is a vehicle security system. In essence it allows a vehicle user to access common vehicle security-related futures, such as locking/unlocking doors and starting/stopping the engine, using a smart phone application or capabilities to assert an identity relating to privileges itself via biometric capabilities or alpha nu- meric input capabilities.
- the SAM will be embedded in the vehicle - either as a discrete module, or as a chipset resident within a host module.
- the SAM will interact with the Platform via a cellular data connection; interaction with the App will utilise Bluetooth but could feasibly be any short range wireless data bearer technology.
- the App will be resident on a smart phone using any of the popular mobile operating systems (e.g., iOS, Android, Windows Mobile) or the App function could be incorporated into the operating system of the asset.
- the App will incorporate all of the cryptographic functionality that is required for it to operate (to remove dependence on the host operating system) and will include a num- ber of security features (see below).
- the Platform represents a logical entity that could have its functions distributed amongst multiple, potentially unrelated, participants.
- the Platform will be treated as a single physical entity4.
- the Platform acts as a CA and AA and incorporates the necessary technology to implement these functions, including database technology to store information about SAMs, Users and their privileges.
- the critical nature of the Platform as the basis of all trust requires that the public keys of the CA and AA are generated, stored and operated within a Hardware Security Module (HSM), with appropriate technical and procedural controls to protect its operation.
- HSM Hardware Security Module
- Registration involves the generation of a key-pair within the SAM cryptographic module; the creation of a signed certificate request and its submission to the CA.
- the SAM must be assigned a unique name (the Subject of the certificate), but it is also possible to incorporate other unique identifiers. In the vehicular context, this would commonly be the "VIN”, Vehicle Identity Num- ber, but also could comprise the Engine number, Chassis number etc.
- SAM Re-Enrolment - deals with renewal of SAM identity credentials.
- This use case has not been developed, but in principle uses EST and the current SAM credential to automatically renew the credential before its expiry.
- the SAM must be able to autonomously make decisions based on its environment or context.
- the concept of a Policy is that it is a set of rules that aids the SAM decision making.
- the policy could include rules such as:
- any contextual elements e.g., time, location, privilege being requested by specific Identified User
- a threshold can be set to either grant that privilege or grant a benefit of doubt privilege that can be dynamically affirmed or rescinded at a point when, for example, full communication access to the platform is re-established and benefit of doubt granted privilege can be affirmed, rescinded or modified.
- a default policy should be installed in the vehicle during manufacture (this is a secure activity, similar in some ways to the SAM registration). Subsequently, a system-level privilege is the ability to change some or all policies. Privileges
- Privilege represents a set of privileges associated with a user; they will normally be contained within an attribute certificate but may only exist within the Platform database or as entries within an external Privilege Providers database until the user requests the attribute certificate. In some cases, an attribute certificate is not required - e.g., interactions with the Platform to create new Privileges (as the Platform knows the Privileges associated with a user).
- Typical privileges associated with a vehicle include:
- Hardware dependent functions such as intelligent cruise control, services derived from sensors, climate control, anthropomorphic adjustments etc.
- the manufacturer When the vehicle is first manufactured, the manufacturer has a 'full' Privilege. In order to transfer control over the vehicle to a Dealer, the manufacturer must grant Privileges to the Dealer.
- a Privilege is associated with a single SAM - the SAM identity is in- eluded in the attribute certificate.
- other security-related information may also be included in the AC - for example, a Bluetooth MAC address.
- a Dealer is an intermediary between the vehicle manufacturer and the end customer (User).
- the Dealer (like the vehicle manufacturer) must re- ceive credentials from the Platform - but it is unlikely that these will be used via a mobile app.
- the use of a smart card or similar cryptographic token to protect the Dealer credentials is recommended.
- the Dealer interacts with the User to register the User with the Platform as well as granting a Privilege to the User for a vehicle - as part of the de- livery process for example.
- a Third Party in this context is somebody with control over the vehicle, typically because they own it (e.g., a finance company, car rental company, etc.). They have the right to grant a Privilege to a User (who is actually going to operate it), but retain control over that Privilege (so it could be revoked if, for example, payments on a finance agreement are not made).
- a User is someone with control over a vehicle who holds the prerequisite privilege and has asserted his identity to enact those privileges to which he has access.
- a User may be the legal owner of the vehi- cle, or a 'temporary' user.
- a vehicle provided under a finance agreement will legally belong to the finance company, in which case the User is a temporary user until the finance agreement ends. In this case it is unlikely that the User would receive the Transfer ownership of the vehicle' privilege.
- the du- ration of a User's access to the vehicle is determined by the validity period of the attribute certificate containing the Privilege.
- a User may grant privileges to other Users, but this is constrained by their own Privilege.
- a User may grant any privilege that they have, or any subset of privilege that they see fit but is contained within their privilege rights as defined by their title to the asset or that offered by the Privilege Provider of the specific privilege function.
- Registration of a User is conducted within the App, which is responsible for creating the key-pair and requesting a PKC from the CA. This could also employ the EST protocol described above, but with some variations. The identity of the User must be verified before the PKC can be issued - this should be undertaken by a trusted party; for the purposes of this discussion it is assumed that this will be the Dealer (but could equally be a finance company, car rental company, etc.).
- the Dealer In PKI terms, the Dealer is acting as a Registration Authority (RA) and provides temporary credentials (a one-time password and serial number) to the User for use in the registration process. These temporary credentials are sufficient to authenticate the User prior to issuing the PKC - the Dealer may capture a range of information about the user for presentation to the Platform (name, email address, mobile phone number, etc.).
- the key-pair is specific to a single App instance, and the User may possess multiple mobile devices, or lose a mobile device, there are a number of use cases around managing this variation. For example, a registered User could 'vouch for' his identity on another App instance. A User is likely to have multiple PKCs associated with his identity.
- a PKC User identity
- AC Privilege
- a mechanism for revoking Privileges is required - although revocation information may be of interest to a User, it is primarily for use by the SAM.
- the SAM may not be connected to a cellular data service at all times
- a 'push' mechanism may not be feasible, if the SAM is not connected to a data service
- the SAM has a finite storage capacity for storing revocation data o Probably not an issue for the general use case
- SMS Short Messages
- the recommended approach is to use SMS messages to push revocation information to the SAM on demand (i.e. following a revocation).
- the use of SMS is suggested because it represents the lowest common denominator for cellular data transfer - in particular it works with a basic 2G/GSM service and does not require access to a data service.
- the SMS revocation message will consist of an identifier for the revoked AC, an expiry date for the revocations and a digital signature.
- the primary purpose of the expiry date is to allow 'garbage collection' by the SAM, to ensure that storage resources are managed; the signature protects against DOS attacks.
- Other methods are also applicable but not contained within this example such as the Open Mobile Alliance Light Weight M2M messaging protocol.
- the Platform will implement an assured delivery mechanism - once a revocation message has been created, the Platform will continue to resend the message until an acknowledgement has been received. [0099] It may be possible to extend this mechanism to the App, but it is probably more efficient for the App to 'collect' revocation data when it is next connected to the Platform. This could be done as an extension to the Privilege granting mechanism - e.g. a request for pending privileges results in the removal of expired and revoked privileges, as well as downloading new ones.
- SAM Policy is required to manage boundary cases (or a potential attack on the SAM).
- the Policy rules could determine how the SAM processes a Privilege if it is not connected to a cellular network, or has not been so for an extended period.
- the primary use cases are focused on the core functionality of the system: The vehicle is manufactured; it is transferred to a Dealer; the Dealer sells the vehicle to a User; the User uses the vehicle.
- Figure 8 illustrates the transfer of the vehicle to the dealer.
- the Vehi- cle Manufacturer creates a Privilege set for the Dealer in respect of the vehicle. This transfers to the SAM full privileges.
- the Dealer downloads the Privilege set for the vehicle SAM and sets a market-specific policy.
- Figure 9 illustrates the transfer of the vehicle from the dealer to the User.
- the Dealer initiates registration of the User and transfers the registration credential (Serial Number/OTP) to the User.
- the User completes registration with the Platform and downloads and installs the PKCs.
- the Dealer creates the Privilege set for the User, and the User downloads this from the Platform.
- Figure 10 illustrates the granting of User access to the vehicle.
- the User connects his mobile phone, for example, to SAM via Bluetooth.
- the de- vices mutually authenticate via TLS.
- the Privilege set is supplied to the SAM, and then the User makes an access request.
- the SAM validates the privilege, granting or denying the access request according to the Privilege received.
- the App must operate in a context where there is no trust in the underlying operating system, or any inputs that are dependent upon the operating system. Note that in a more highly controlled environment, it may be possible to gain some trust in the underlying platform services offered by the operating system, but in this context it is not practicable. [00107] The App must protect the User credentials (private key, PKCS, Privileges) on behalf of the User. It is important, therefore, that interaction between the User and the App is preceded by robust authentication of the person claiming to be the User. It is strongly recommended that a multi-factor approach is adopted, using a combination of: ⁇ PIN or passphrase
- the SAM has less surface to attack compared to the App.
- a self-contained firmware environment that in- cludes all cryptographic functions and is digitally signed will reduce the risk of attack.
- continuous communication between the authenticator and the access device may not be possible.
- the access device is associated with a movable set of resources such as a motor vehicle
- the user may wish to exercise the privileges at a location where radio-based communication is not possible - an underground parking garage, say.
- the vehicle could be provided with an externally-accessible interface by which the user can establish identity to the access device if a separate token or key, or a smart phone is not used.
- the access device can then use pre-stored data, downloaded when communi- cation was possible between the authenticator and the access device, to determine whether interim exercise of privileges should be granted.
- the initial identity data might be transmitted to the car on making of the booking, or as soon afterwards as communication with the car is possible, to be stored in a secure cache in the access device until the user wishes to commence use of the car.
- the access device may then request the user to confirm identity, for example within a predetermined time, as a condition for continued grant exercise of the privileges, or as a condition for exercise of the full range of privileges as opposed to a limited sub-set of privileges.
- Asset - A physical or non-physical entity which provides service, function or value to a person or entity with appropriate ownership or privilege to access or facilitate such from the asset or contained within.
- SAM Secure Access Module
- ASIC Application Specific integrated circuit
- Privilege Capabilities A roster of specific functions or capabilities available within an Asset to which privilege can be appended.
- Privilege Provider An external function for the procurement and deliver of specific service or functions available within the roster of Privilege capabilities within an Asset.
Landscapes
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Engineering & Computer Science (AREA)
- Human Computer Interaction (AREA)
- Computer Networks & Wireless Communication (AREA)
- Mobile Radio Communication Systems (AREA)
- Lock And Its Accessories (AREA)
Abstract
Description
Claims
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
GB1314172.6A GB2516939A (en) | 2013-08-07 | 2013-08-07 | Access authorisation system and secure data communications system |
PCT/GB2014/052429 WO2015019104A2 (en) | 2013-08-07 | 2014-08-07 | Access and control authorisation system |
Publications (1)
Publication Number | Publication Date |
---|---|
EP3031036A2 true EP3031036A2 (en) | 2016-06-15 |
Family
ID=49224326
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP14762052.0A Ceased EP3031036A2 (en) | 2013-08-07 | 2014-08-07 | Access and control authorisation system |
Country Status (3)
Country | Link |
---|---|
EP (1) | EP3031036A2 (en) |
GB (1) | GB2516939A (en) |
WO (1) | WO2015019104A2 (en) |
Families Citing this family (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10124750B2 (en) * | 2016-04-26 | 2018-11-13 | Honeywell International Inc. | Vehicle security module system |
CN105976466B (en) * | 2016-05-03 | 2020-01-10 | 科世达(上海)管理有限公司 | Automobile entrance guard door opening method |
CN105976472A (en) * | 2016-05-20 | 2016-09-28 | 科世达(上海)管理有限公司 | Access control permission management method and access control permission system for automobiles |
US10663965B2 (en) * | 2016-09-01 | 2020-05-26 | Ford Global Technologies, Llc | Permissions for partially autonomous vehicle operation |
US20180082053A1 (en) * | 2016-09-21 | 2018-03-22 | Telefonaktiebolaget Lm Ericsson (Publ) | Application token through associated container |
DE102016011654A1 (en) * | 2016-09-27 | 2017-04-06 | Daimler Ag | Method for controlling an access authorization and / or driving authorization for a vehicle |
EP3439258B1 (en) * | 2017-07-31 | 2020-05-27 | Harman International Industries, Incorporated | Data protection and security for in-vehicle systems |
EP3688961B1 (en) * | 2017-09-29 | 2023-05-17 | Visa International Service Association | Federated closed-loop system |
CN113228014A (en) * | 2018-12-21 | 2021-08-06 | 因温特奥股份公司 | Establishing a protected data communication connection between a control device of a people mover and a mobile device |
CN112699354A (en) * | 2019-10-22 | 2021-04-23 | 华为技术有限公司 | User authority management method and terminal equipment |
CN111540100B (en) * | 2020-01-22 | 2022-05-17 | 中国银联股份有限公司 | Data processing method and system based on asynchronous pre-authorization and offline data authentication |
CN112434281B (en) * | 2020-11-17 | 2024-04-30 | 芽米科技(广州)有限公司 | Multi-factor identity authentication method oriented to alliance chain |
CN114465814A (en) * | 2022-03-11 | 2022-05-10 | 江苏天创科技有限公司 | Zero trust safety protection system and protection method |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20070096870A1 (en) * | 2005-10-26 | 2007-05-03 | Sentrilock, Inc. | Electronic lock box using a biometric identification device |
EP2493232A1 (en) * | 2011-02-24 | 2012-08-29 | Research In Motion Limited | Personnel access system with verification features utilizing near field communication (nfc) and related methods |
Family Cites Families (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1271418A1 (en) * | 2001-06-27 | 2003-01-02 | Nokia Corporation | Method for accessing a user operable device of controlled access |
JP4403985B2 (en) * | 2005-02-22 | 2010-01-27 | トヨタ自動車株式会社 | Vehicle remote control device |
SE529849C2 (en) * | 2006-04-28 | 2007-12-11 | Sics Swedish Inst Of Comp Scie | Access control system and procedure for operating the system |
SG187994A1 (en) * | 2011-08-10 | 2013-03-28 | Certis Cisco Security Pte Ltd | An access control system |
KR101304617B1 (en) * | 2011-10-07 | 2013-09-05 | 엘에스산전 주식회사 | Method for user authentication in in-home display |
DE102011122461A1 (en) * | 2011-12-22 | 2013-06-27 | Airbus Operations Gmbh | Access system for a vehicle and method for managing access to a vehicle |
US20130257589A1 (en) * | 2012-03-29 | 2013-10-03 | Mohammad MOHIUDDIN | Access control using an electronic lock employing short range communication with mobile device |
-
2013
- 2013-08-07 GB GB1314172.6A patent/GB2516939A/en not_active Withdrawn
-
2014
- 2014-08-07 EP EP14762052.0A patent/EP3031036A2/en not_active Ceased
- 2014-08-07 WO PCT/GB2014/052429 patent/WO2015019104A2/en active Application Filing
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20070096870A1 (en) * | 2005-10-26 | 2007-05-03 | Sentrilock, Inc. | Electronic lock box using a biometric identification device |
EP2493232A1 (en) * | 2011-02-24 | 2012-08-29 | Research In Motion Limited | Personnel access system with verification features utilizing near field communication (nfc) and related methods |
Also Published As
Publication number | Publication date |
---|---|
GB201314172D0 (en) | 2013-09-18 |
WO2015019104A2 (en) | 2015-02-12 |
WO2015019104A3 (en) | 2015-06-11 |
GB2516939A (en) | 2015-02-11 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
WO2015019104A2 (en) | Access and control authorisation system | |
US10829088B2 (en) | Identity management for implementing vehicle access and operation management | |
CN109727358B (en) | Vehicle sharing system based on Bluetooth key | |
EP3460693B1 (en) | Methods and apparatus for implementing identity and asset sharing management | |
EP3312750B1 (en) | Information processing device, information processing system, and information processing method | |
US10645578B2 (en) | System for using mobile terminals as keys for vehicles | |
US10205711B2 (en) | Multi-user strong authentication token | |
US9361452B2 (en) | Mobile credential revocation | |
CN111835689B (en) | Identity authentication method of digital key, terminal device and medium | |
EP3576378B1 (en) | Transferring control of vehicles | |
EP3460691A1 (en) | Methods and apparatus for management of intrusion detection systems using verified identity | |
JP2020511069A (en) | System access using mobile devices | |
JP2019523513A (en) | Communication flow for confirmation and ID check | |
KR102426930B1 (en) | Method for managing digital key of mobile device for vehicle-sharing and key server using the same | |
CN112330855B (en) | Electronic lock safety management method, equipment and system | |
JP2017531112A5 (en) | ||
CN108701384B (en) | Method for monitoring access to electronically controllable devices | |
CN105849740B (en) | Method for controlling data supply and terminal equipment | |
EP2976752B1 (en) | Secure electronic lock | |
CN110770800B (en) | Method for granting access rights | |
JP2004533730A (en) | Process and apparatus for improving security of digital signature and public key infrastructure for real world applications | |
CN109359450A (en) | Safety access method, device, equipment and the storage medium of linux system | |
US20220138747A1 (en) | Round trip resource sharing method with time slot locking | |
JP2002096715A (en) | Method for authorization of driver, its system and its recording medium | |
CN115987636B (en) | Information security implementation method, device and storage medium |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
17P | Request for examination filed |
Effective date: 20160304 |
|
AK | Designated contracting states |
Kind code of ref document: A2 Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
|
AX | Request for extension of the european patent |
Extension state: BA ME |
|
RAP1 | Party data changed (applicant data changed or rights of an application transferred) |
Owner name: SHAW, EMMA JANE |
|
DAX | Request for extension of the european patent (deleted) | ||
17Q | First examination report despatched |
Effective date: 20180301 |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R003 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED |
|
18R | Application refused |
Effective date: 20200710 |