阅读说明：本技术 用于基于策略的资产的管理的方法和装置 (Method and apparatus for policy-based asset management ) 是由 Y·埃夫特卡里鲁茨贝哈尼 C·利姆 于 2019-01-08 设计创作，主要内容包括：一种用于管理资产的共享使用的方法和系统。资产设备和所有者设备完成初始设置程序以向资产注册所有者。然后,从所有者设备或被授权创建策略的另一设备向一个或多个用户设备发送一个或多个安全策略。策略表达使用资产的用户条件和限制。随后,用户设备向资产设备发射安全策略。一旦策略已经从用户设备转移到资产设备,与用户设备相关联的用户就可以请求资产的使用,并且如果策略允许所请求的使用,则用户将被授予所请求的使用。(A method and system for managing shared use of assets. The asset device and owner device complete an initial setup procedure to register the owner with the asset. One or more security policies are then sent to one or more user devices from the owner device or another device authorized to create the policies. The policy expresses user conditions and restrictions on using the asset. The user device then transmits the security policy to the asset device. Once the policy has been transferred from the user device to the asset device, a user associated with the user device may request use of the asset and, if the policy allows the requested use, the user will be granted the requested use.)

1. A method implemented by one or more computing devices for managing use of assets, the method comprising:

completing a registration process between an asset device associated with an asset and an owner device associated with an owner of the asset;

transmitting a security policy associated with the user from a policy owner device to a user device associated with a user, wherein the security policy expresses conditions and restrictions for using the asset and is different from an encryption key used to secure the communication to the asset;

transmitting the security policy from a user device to the asset device;

requesting, by the user device, a specified use of the asset; and

the request is granted only if the policy allows use of the request.

2. The method of claim 1, wherein the security policy is bound to a fingerprint of the user device, and further comprising the policy owner device encrypting and signing the policy.

3. The method of claim 2, wherein the policy owner device is controlled by the owner of the asset.

4. The method of claim 2, wherein the policy owner device is controlled by a party other than the owner of the asset that has been given the right to create a policy.

5. The method of claim 2, wherein the asset device stores a data structure comprising a user ID, a user fingerprint, an access policy attribute, and a shared secret with the owner device, and wherein the owner device stores a data structure comprising an asset ID, an asset fingerprint, an access policy attribute, and the shared secret.

6. The method of claim 2, wherein the user device stores a data structure comprising an asset ID and an asset fingerprint and a shared secret with the policy owner.

7. The method of claim 2, wherein the use of the asset comprises physical access to an interior of the asset.

8. The method of claim 2, wherein the asset is a computing resource and the use comprises access to the computing resource.

9. The method of claim 1, wherein the registration process comprises:

exchanging a public key between the owner device and the asset device, the public key being signed with an identity certificate signature by a certificate authority;

deriving a shared secret; and

securing the communication between the owner device and the asset device by encrypting and signing the communication using the public key and the shared secret.

10. An apparatus for managing use of assets, the apparatus comprising:

at least one computer processor;

at least one memory device coupled to the at least one computer processor and storing instructions thereon, which when executed by the at least one processor, cause the at least one processor to:

completing a registration process between an asset device associated with an asset and an owner device associated with an owner of the asset;

transmitting a security policy associated with the user from a policy owner device to a user device associated with a user, wherein the security policy expresses conditions and restrictions for using the asset and is different from an encryption key used to secure the communication to the asset;

transmitting the security policy from a user device to the asset device;

requesting, by the user device, a specified use of the asset; and

the request is granted only if the policy allows use of the request.

11. The apparatus of claim 10, wherein the security policy is bound to a fingerprint of the user device, and further comprising the policy owner device encrypting and signing the policy.

12. The apparatus of claim 10, wherein the policy owner device is controlled by the owner of the asset.

13. The apparatus of claim 10, wherein the policy owner device is controlled by a party other than the owner of the asset that has been given the right to create a policy.

14. The apparatus of claim 10, wherein the asset device stores a data structure comprising a user ID, a user fingerprint, an access policy attribute, and a shared secret with the owner device, and wherein the owner device stores a data structure comprising an asset ID, an asset fingerprint, an access policy attribute, and the shared secret.

15. The apparatus of claim 10, wherein the user device stores a data structure comprising an asset ID and an asset fingerprint and a shared secret with the policy owner.

16. The apparatus of claim 10, wherein the use of the asset comprises physical access to an interior of the asset.

17. The apparatus of claim 10, wherein the asset is a computing resource and the use comprises access to the computing resource.

18. The apparatus of claim 10, wherein the registration process comprises:

exchanging a public key between the owner device and the asset device, the public key being signed with an identity certificate signature by a certificate authority;

deriving a shared secret; and

securing the communication between the owner device and the asset device by encrypting and signing the communication using the public key and the shared secret.

Background

The present invention relates to managing and controlling access to assets based on policies. The recent concept of "shared economy" has resulted in many assets being shared between different entities that are sometimes otherwise unrelated. For example, it is known to share car, house and apartment, bicycle and office space. Other examples of sharing include granting temporary access to mailboxes, vehicles, or premises to delivery personnel or others who require specific access. Of course, it is known to grant physical access to an asset by copying a physical key. Examples of commercial sharing include AirBnB ™ chambers (lodging), ZipCar @, and Greenboards ™ chambers (car), LiquidOffice @ (office space) Velib (bike), and Amazon Key @ (package delivery access to your home). Furthermore, rental vehicles are long-term shares of vehicles (e.g., years). In some cases, the business industry is experimenting with very short term vehicle rentals (e.g., on a monthly basis). In another example, we can consider passengers on a public transport (e.g., bus, train) as another sharing example. The passenger is given temporary access to the train under appropriate conditions (e.g., the fee is paid). In yet another example, the OEM may rent equipment (e.g., trucks, agricultural equipment, mining equipment, engines) to an operator based on the amount of time the equipment is running rather than on a time-based basis.

In some instances, a Near Field Communication (NFC) tag or other token is used to grant access to an asset. Conventional systems of access management require significant infrastructure and are inflexible with respect to granting personalized access conditions/constraints. For example, in the case of physical key access, it is not possible to personalize the access conditions for the user, for example to a specific time window. Similar problems arise in granting access to a computing device or other resource.

To complicate matters, shared assets are often deployed into "hostile environments" (such as situations where a potential criminal has full access to the most critical hardware components, excessive analysis time, and motivation driven by huge opportunities). For example, access to an office space or home provides physical access to computing devices and other valuables therein. An attacker may have multiple goals including stealing the asset itself, tampering/modifying the policy that controls the asset, and reverse engineering policy management.

There are various types of known digital solutions for sharing access to assets between different entities. A fully connected solution, where the asset and the sharing entity need to be connected to a remote server, is undesirable, mainly because in some cases connectivity of the asset to the server is not available. For example, in a vehicle sharing arrangement, a vehicle may park in an underground parking structure without connectivity.

Partially connected solutions (where the asset does not require any type of network connection, but the sharing entity does require such a connection) also have limitations. One major drawback of such systems is that they are difficult to tune to different providers and manufacturers. Providers and manufacturers often host their own cloud services and desire full control over their deployment. This means that the key sharing provider must integrate with the proprietary infrastructure, making it very difficult to scale to multiple providers and manufacturers. Moreover, such solutions typically require entities to have the same shared application, which is restrictive in some use cases. For example, if a vehicle owner wants to grant access to their vehicle to a temporary user (such as a valet parking car), the temporary user must install an application on their personal device for a limited time. This problem is compounded when, for example, a valet parking garage needs to download multiple apps to be able to access several different brands of vehicles.

An offline solution that relies only on in-range wireless communication (such as bluetooth or NFC) between the sharing entity and the asset relies on the fact that all users share the same encryption key for the asset. In addition to being a security risk, these solutions make it very difficult to create custom constraints for different types of users of an asset.

Drawings

The foregoing summary, as well as the following detailed description of the invention, will be better understood when read in conjunction with the appended drawings. For the purpose of illustrating the invention, there are shown in the drawings various illustrative embodiments. It should be understood, however, that the invention is not limited to the precise arrangements and instrumentalities shown.

In the drawings:

FIG. 1 is an overview schematic of a system workflow;

FIG. 2 is a data flow diagram of an initial asset setup operation of an embodiment;

FIG. 3 is a data flow diagram of a policy transfer operation of an embodiment;

FIG. 4 is a data flow diagram of an asset access operation of an embodiment;

FIG. 5 is a data flow diagram of a third party asset access operation of an embodiment;

FIG. 6 is a data flow diagram of an initial setup operation in a vehicle sharing use case of the embodiment;

FIG. 7 is a data flow diagram of a policy transfer operation in a vehicle sharing use case of an embodiment;

FIG. 8 is a data flow diagram of an asset access operation with vehicle sharing use of an embodiment.

Detailed Description

Certain terminology is used in the following description for convenience only and is not limiting. Unless specifically set forth herein, the terms "a," an, "and" the "are not limited to one element, but rather should be construed to mean" at least one. The terminology includes the words above mentioned, derivatives thereof and words of similar import.

The present invention provides a system and method for creating, managing, applying, and enforcing policies in an asset sharing environment. The present invention provides a novel policy management data model, distributed computer communication architecture and workflow that results in advantageous operation of computer systems applied to a shared environment. The present invention is applicable to a number of use cases, including

Vehicle rental: allowing access to the vehicle through the mobile app. The occupant can order the vehicle online without having to go to the local office or have a physical key. The service may also include a pay-per-view type model where you only pay for the vehicle's mileage and usage.

Personal vehicle sharing: the car owner may grant access to the vehicle to his family, valet, or friend.

Allow delivery to the asset: in the case of a vehicle, this may be a night trunk delivery. In the case of a house, this may be a delivery to a mailbox. Access is granted to members of a third party such as DHL/Amazon.

Automobile as a service (CaaS): ride sharing for automotive vehicles

Fleet management of trucks

Management of bus operators

Building access: people can get access to different floors, doors, sectors of a building based on their policy. The policy may also enforce time of day and day of week access constraints.

Smart home solutions: one may gain access to the mail/drop box for delivery, access to the front door only, access to the time of day/day of week of the house, grant access to friends and family when away.

House rentals and B & B: you can grant access to others who use the property. This can be used for small wooden houses, villages, B & B, cleaning services, etc.

In the embodiments described herein, the policy replaces the digital/physical access key and is different from the encryption key used to secure communications to the asset. To minimize the risk of an attack, the policy is sent once to the asset protected and enforced by the asset for each use. The policy owner is an authorized entity and may generate a new policy for the secondary user. The policies generated for the secondary users may be constrained in number and scope by the authorizing entity. For example, the secondary user may be constrained to a speed limit and have no access to the luggage. The granted policies may also include authorization policies. For example, a vehicle owner may enable his/her teenager to generate a new policy for a friend may impose tighter constraints on what the teenager may authorize.

Authorizing the policy owner to generate new policies scatters access management, which in turn greatly reduces operating costs. For example, instead of having the facility manager grant NFC tag access to all staff, the operations manager may grant access to their direct reporting staff. Embodiments support all modes of connectivity, such as: neither the asset nor the user is connected, the user is connected but the asset is not connected, and both the user and the asset are connected. In other words, the policy authorization and generation mechanism may be independent of communication between entities. There is no need for a master authorization broker to be present.