[001] Generally, the invention relates to generation and management of keys. More specifically, the invention relates to a method and a system of key generation and management for smart-device based keyless access to assets.

Background
[002] A keyless access system allows controlled access to a protected system without requiring a physical key. The keyless access system is evolution of a traditional lock system where various techniques have been employed to build a keyless lock that eliminates need to carry physical keys. Examples of these techniques include Combination Lock, Keypad Lock, Biometric-recognition based Lock, and Radio-signal based Lock.
[003] The widespread adoption of smartphones among global population has opened new potential applications of smartphone-based keyless access system in variety of scenarios such as a vehicle, an equipment, a machinery, an electronic safe, a self-storage, a building, and the like. Therefore, there is a need in the present state of art for the smartphone-based keyless access system that may use smartphone’s in-built security, encryption, and networking capabilities to effectively replace the need of carrying physical keys.

SUMMARY OF INVENTION
[004] In one embodiment, a method of generation and management of keys for smart device based keyless access to an asset is disclosed. The method may include generating a base key associated with an asset and a base key metadata. The base key includes a base private key and a base public key. The method may further include generating a main key and a main key metadata. The main key may be associated with the asset and a first smart device of a primary user, and the main key may include a main private key and a main public key. The method may further include sharing of: the base private key, the main public key, and a base permission list with the asset and the base public key, the main private key, and the base permission list with the first smart device. The main private key may enable the primary user, via the first smart device, to gain keyless access to the asset.
[005] In another embodiment, a system of generation and management of keys for smart device based keyless access to an asset is disclosed. The system may include a key generation device comprising a processor and a memory communicatively coupled to the processor. The memory may store processor-executable instructions, which, on execution, may causes the processor to generate a base key associated with an asset and a base key metadata. The base key includes a base private key and a base public key. The processor-executable instructions, on execution, may further cause the processor to generate a main key and a main key metadata. The main key may be associated with the asset and a first smart device of a primary user, and the main key may include a main private key and a main public key. The processor-executable instructions, on execution, may further cause the processor to share of: the base private key, the main public key, and a base permission list with the asset and the base public key, the main private key, and the base permission list with the first smart device. The main private key may enable the primary user, via the first smart device, to gain keyless access to the asset.
[006] It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS
[007] The present application can be best understood by reference to the following description taken in conjunction with the accompanying drawing figures, in which like parts may be referred to by like numerals.
[008] FIG. 1 is an environment diagram illustrating a system of key generation for smart device based keyless access to assets, in accordance with an embodiment.
[009] FIG. 2 is a block diagram of the key generation device configured to key generation of smart device based keyless access to assets, in accordance with an embodiment.
[010] FIG. 3 illustrates a block diagram for generating a base key, in accordance with an embodiment.
[011] FIG. 4 illustrates a block diagram for generating a main key, in accordance with an embodiment.
[012] FIG. 5 illustrates a block diagram for generating additional key via a server application, in accordance with an embodiment.
[013] FIG. 6 illustrates a block diagram for Smartphone-to-Asset (S2A) secure data transfer, in accordance with an embodiment.
[014] FIG. 7 illustrates block diagram for Asset-to-Smartphone (A2S) secure data transfer, in accordance with an embodiment.
[015] FIG. 8 illustrates a block diagram for Smartphone-to-Smartphone (S2S) secure data transfer, in accordance with an embodiment.
[016] FIG. 9 illustrates a block diagram for generating additional key via a mobile application of primary user, in accordance with an embodiment.
[017] FIG. 10 illustrates a block diagram for sharing additional key with secondary smartphone, in accordance with an embodiment.
[018] FIG. 11 illustrates a block diagram for revoking additional key is illustrated, in accordance with an embodiment.
[019] FIG. 12 illustrates a block diagram for establishing a trusted location-based service context between asset and iPhone, in accordance with an embodiment.
[020] FIG. 13 is a flowchart of a method for generating and managing keys for smart device based keyless access to an asset, in accordance with an embodiment.
[021] FIG. 14 is a flowchart of a method for generating additional key, in accordance with an embodiment.
[022] FIG. 15 is a flowchart of a method for sharing additional key with asset, in accordance with an embodiment.
[023] FIG. 16 is a flowchart of a method for sending and receiving a first message from first smart device to asset, in accordance with an embodiment.
[024] FIG. 17 is a flowchart of a method for sending and receiving a first message from second smart device to asset, in accordance with an embodiment.
[025] FIG. 18 is a flowchart of a method for sending and receiving a second message from asset to first smart device, in accordance with an embodiment.
[026] FIG. 19 is a flowchart of a method for sending and receiving a second message from asset to second smart device, in accordance with an embodiment.
[027] FIG. 20 is a flowchart of a method for exchanging a third message between first smart device and second smart device, in accordance with an embodiment.
[028] FIG. 21 is a block diagram of an exemplary computer system for implementing embodiments consistent with the present disclosure.

DETAILED DESCRIPTION OF THE DRAWINGS
[029] The following description is presented to enable a person of ordinary skill in the art to make and use the invention and is provided in the context of particular applications and their requirements. Various modifications to the embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the invention. Moreover, in the following description, numerous details are set forth for the purpose of explanation. However, one of ordinary skill in the art will realize that the invention might be practiced without the use of these specific details. In other instances, well-known structures and devices are shown in block diagram form in order not to obscure the description of the invention with unnecessary detail. Thus, the invention is not intended to be limited to the embodiments shown but is to be accorded the widest scope consistent with the principles and features disclosed herein.
[030] While the invention is described in terms of particular examples and illustrative figures, those of ordinary skill in the art will recognize that the invention is not limited to the examples or figures described. Those skilled in the art will recognize that the operations of the various embodiments may be implemented using hardware, software, firmware, or combinations thereof, as appropriate. For example, some processes can be carried out using processors or other digital circuitry under the control of software, firmware, or hard-wired logic. (The term “logic” herein refers to fixed hardware, programmable logic and/or an appropriate combination thereof, as would be recognized by one skilled in the art to carry out the recited functions.) Software and firmware can be stored on computer-readable storage media. Some other processes can be implemented using analog circuitry, as is well known to one of ordinary skill in the art. Additionally, memory or other storage, as well as communication components, may be employed in embodiments of the invention.
[031] Referring now to FIG. 1, an environment diagram illustrating a system 100 of key generation for smart device based keyless access to assets is illustrated, in accordance with an embodiment. The system 100 may include a key generation device 102 that may be responsible for generating keys for the smart device based keyless access to an asset. Examples of the key generation device 102 may include, but are not limited to, a server, a desktop, a laptop, a notebook, a tablet, a smartphone, a mobile phone, an application server, or the like. Examples of the asset may include, but are not limited to, a vehicle, an equipment, a machinery, an electronic safe, a self-storage, a building, or the like. Examples of the smart device may include, but are not limited to, an iPhone, an android phone, a blackberry, a windows phone, or the like.
[032] In order to generate keys for the smart device based keyless access to the asset, initially, the key generation device 102 may generate a base key associated with the asset and a base key metadata. The base key may include a base private key and a base public key.
[033] Once the base key and the base key metadata are generated, the key generation device 102 may further generate a main key and a main key metadata. The main key may be associated with the asset and a first smart device of a primary user, and the main key may include a main private key and a main public key. It should be noted that, the metadata associated with the base key and the main key may include information related to unique identity (id) of keys, keys creation timestamp information, keys created information, type of keys (for example, the base key, the main key, or an additional key), keys owner information, keys validity information, current status of keys (for example, generated, provisioned, expired, or revoked), keys expiry timestamp, and other information as required to implement specific use case. The keys metadata (for example, the based key metadata, and the main key metadata) may be utilized to track key lifecycle and key management.
[034] Once the base key and the main key are generated, the key generation device 102 may further share the base private key, the main public key, and a base permission list with the asset. In some embodiments, the key generation device 102 may share the base public key, the main private key, and the base permission list with the first smart device. The main private key may enable the primary user to gain keyless access to the asset via the first smart device. The complete process followed by the system 100 is further explained in detail in conjunction with FIG. 2 to FIG. 21.
[035] The key generation device 102 may further include a processor 104 that is communicatively coupled to a memory 106 which may be a non-volatile memory or a volatile memory. Examples of non-volatile memory, may include, but are not limited to a flash memory, a Read Only Memory (ROM), a Programmable ROM (PROM), Erasable PROM (EPROM), and Electrically EPROM (EEPROM) memory. Examples of volatile memory may include, but are not limited Dynamic Random Access Memory (DRAM), and Static Random-Access Memory (SRAM).
[036] The memory 106 may store instructions that, when executed by the processor 104, may cause the processor 104 to generate keys for smart device based keyless access to assets. As will be described in greater detail in conjunction with FIG. 2 to FIG. 21, in order to generate keys, the processor 104 in conjunction with the memory 106 may perform various functions including generating a base key associated with an asset and a base key metadata, generating a main key and a main key metadata, and then sharing the base private key, the main public key, and a base permission list with the asset, or the first smart device.
[037] The system 100 may further include a display 108. The display 108 may include a user interface 110. The end-user may interact with the key generation device 102 and vice versa via the user interface 110 accessible via the display 108. By way of an example, the display 108 may be used to display results (i.e., the generated base key and the main key) based on actions performed by the key generation device 102, to the end-user (i.e., asset owner).
[038] The system 100 may also include one or more external devices 112. In some embodiments, the key generation device 102 may interact with the one or more external devices 112 over a communication network 114 for sending or receiving various data. Examples of the external devices 112 may include, but are not limited to, computer, tablet, smartphone, and laptop. The communication network 114, for example, may be any wired or wireless network and the examples may include, but may be not limited to, the Internet, Wireless Local Area Network (WLAN), Wi-Fi, Long Term Evolution (LTE), Worldwide Interoperability for Microwave Access (WiMAX), and General Packet Radio Service (GPRS).
[039] Referring now to FIG. 2, a block diagram of the key generation device 102 configured to key generation of smart device based keyless access to assets is illustrated, in accordance with an embodiment. The key generation device 102 may include a server application 202a installed on a server-side 202, an asset application 204a installed on a connected asset 204, and a mobile application 206a installed on the smart device (for example, a smartphone 206).
[040] The server application 202a may be integrated with an existing connected asset solution 202b that enables server-side admin users to generate a base key for the connected asset 204 and a main key for the smartphone 206 of a primary user. It should be noted that, the primary user may be an owner of the asset 204. The base key may be securely stored in the asset 204 that is to be accessed and may be used during transfer of trusted data from the asset 204 to the smartphone 206 of the asset owner.
[041] Additionally, the main key may be securely stored in the smartphone 206 of the asset owner and may be used to access the asset 204 and may have full access permissions over the asset 204. The main key may further be used to transfer of trusted data from the smartphone 206 to the asset 204 during access of the asset 204. The transmission of trusted data from the mobile application 206a to the asset application 204a or vice versa may be done over an established datalink. The datalink may be established either using Bluetooth (BLE), internet, or Near-field communication (NFC).
[042] In some embodiments, the key generation device 102 may generate an additional key for a secondary user. The secondary user may be a user other than the asset owner. Examples of the secondary user may be, but are not limited to, a driver, a child, a friend, a neighbor, or the like. In other words, the additional key may be generated when the secondary user request for accessing the asset 204 owned by the primary user. The additional key may be generated either by the mobile application 206a that is installed within the smartphone 206 of the asset owner or by the server application 202a of the server-side 202. This is explained in greater detail in conjunction with FIG. 5 and FIG. 9. Further, the additional key may be shared with limited access rights to each of the secondary user only after successful authentication.
[043] The asset application 204a may be integrated with an existing in-asset solution 204b to manage the asset’s base key, the main key, and the additional key. The mobile application 206a may be integrated with an existing connected asset mobile application 206b to manage the asset’s main Key and the additional key.
[044] Referring now to FIG. 3, a block diagram for generating a base key is illustrated, in accordance with an embodiment. In order to generate the base key on the server-side 202, initially, an admin level user may initiate a key provisioning at the server application 202a. Further, a base permission list 304 may be derived from asset’s capabilities and may be stored in the storage 302 of the server application 202a.
[045] Once the base permission list 304 is stored in the storage 302, a set of base key objects 306 may be created that includes a base private key 308, a base public key 310, and a base key metadata 312. Further, the base permission list 304 and the base private key 308 may be sent to the asset application 204a. The asset application 204a may save the received base permission list 304 and the base private key 308 into a storage 314.
[046] It may be noted that, only one pair of the base key (for example, the base private key 308 and the base public key 310) may be generated for each asset at any point of time. The generation of new pair of the base key may require the asset application 204a and the mobile application 206a of the primary user’s smartphone to download and replace to the new pair of the base key. The base key may be regenerated by following the same process as discussed above whenever required, in particular, when the base key is found to be compromised.
[047] Referring now to FIG. 4, a block diagram for generating a main key is illustrated, in accordance with an embodiment. Once the base key is generated, the admin level user may further request the server application 202a to generate a main Key for the asset 204 at the server-side 202. In order to generate the main key, initially, a set of main key objects 402 may be created and stored in the storage 302 of the server application 202a. The set of main key objects 402 may include a main private key 408, a main public key 406, and a main key metadata 404.
[048] Further, the main public key 406 may be sent to the asset application 204a. The asset application 204a may further saves the main public key 406 into the storage 314. The server application 202a may send the base permission list 304, the base public key 310, and the main private key 408 from the storage 302 to the mobile application 206a. The base permission list 304, the base public key 310, and the main private key 408 may further be saved in a storage 410 of the mobile application 206a.
[049] The main private key 408 may be used to carry out unrestricted privileged operations from the mobile application 206a of the smartphone 206. It may be noted that, only one pair of the main key (for example, the main public key 406 and the main private key 408) may be generated for each asset at any point of time. The generation of new pair of the main key may require the asset application 204a and the mobile application 206a of the primary user’s smartphone to download and replace to the new pair of the main key. The main key may be regenerated by following the same process as discussed above in conjunction with the present FIG. 4. The main key may be regenerated in case when the main key is found to be compromised.
[050] Referring now to FIG. 5, a block diagram for generating additional key via server application is illustrated, in accordance with an embodiment. As mentioned earlier in reference to FIG. 3, the additional key may be generated when requested by the secondary user to access the asset 204 of the primary user. The additional key may be generated either by the mobile application 206a that is installed within the smartphone 206 of the primary user, or by the server application 202a at the server-side 202. The present FIG. 5 illustrates the generation of additional key via the server application 202a. Initially, the admin level user may request to generate the additional key at the server-side 202 via the server application 202a.
[051] Further, a set of additional key objects 502 may be created. The set of additional key objects 502 may include an additional private key 504, an additional public key 506, an additional permission list 508, and an additional metadata 510. It may be noted that, the set of additional key objects 502 may be stored in the storage 302 of the server application 202a. Further, the additional public key 506 may be sent to the asset application 204a.
[052] The asset application 204a may then save the additional public key 506 in the storage 314. The server application 202a may send the additional permission list 508, the base public key 310, and the additional private key 504 from the storage 302 to the mobile application 206a. The mobile application 206a may further save the additional permission list 508, the base public key 310, and the additional private key 504 in the storage 410.
[053] The additional private key may be used to carry out operations from the mobile application 206a of the smartphone 206 as specified in the additional permission list 508. In some embodiments, the additional key may be revoked and deleted from the asset 204 in case when the asset 204 is no longer to be shared with the secondary user.
[054] Referring now to FIG. 6, a block diagram for Smartphone-to-Asset (S2A) secure data transfer is illustrated, in accordance with an embodiment. In order to transfer data securely from the S2A, the mobile application 206a of the smartphone 206 may be required to have the main private key 408, or the additional private key 504 stored in the storage 410. Further, the asset application 204a of the asset 204 may be also required to have the main public Key 406, or the additional public key 506 stored in the storage 314 for the S2A secure data transfer.
[055] For example, in case when the data is to be transferred from a smartphone of the secondary user (for example, a secondary smartphone associated the user other than the asset owner) to the asset 204, then the mobile application 206a may be required to have the additional private key 504 stored in the storage 410. In a similar manner, when the data is to be transferred from the smartphone 206 of the primary user (for example, a primary smartphone associated with the asset owner) to the asset 204, then the mobile application 206a may be required to have the main private key 408 stored in the storage 410.
[056] Further, the mobile application 206a may encrypt data that is to be transferred from S2A in a form of first message using the base public key 310. Once the data is encrypted, the mobile application 206a may further signs the first message using one of the main private key 408 or the additional private key 504. The encrypted and signed message may further be transmitted from the mobile application 206a to the asset application 204a over an established datalink. The datalink may be established either using BLE, internet, or NFC.
[057] Once the first message is transmitted to the asset application 204a, the asset application 204a may further verify the first message using one of the main public Key 406 or the additional public key 506. The asset application 204a may further decrypt the first message using the base private key 308 in response to the verification.
[058] Referring now to FIG. 7, a block diagram for Asset-to-Smartphone (A2S) secure data transfer is illustrated, in accordance with an embodiment. In order to initiate the data transfer from A2S securely, the mobile application 206a of the smartphone 206 may be required to have the base public key 310 and one of the main private key 408 or the additional private key 504 stored in the storage 410. Further, the asset application 204a of the asset 204 may be also required to have the base private key 308 and one of the main public Key 406, or the additional public key 506 stored in the storage 314 for the A2S secure data transfer.
[059] For example, in case when the data is to be transferred from the asset 204 to the smartphone of the secondary user (for example, the secondary smartphone associated with the user other than the asset owner), then the mobile application 206a may be required to have the base public key 310 and the additional private key 504 stored in the storage 410. In a similar manner, when the data is to be transferred from the asset 204 to the smartphone 206 of the primary user for example, the primary smartphone associated with the asset owner), then the mobile application 206a may be required to have the base public key 310 and the main private key 408 stored in the storage 410.
[060] Further, the asset application 204a may encrypt data that is to be transferred from A2S in a form of second message using the main public Key 406 or the additional public key 506. Once the data is encrypted, the asset application 204a may further signs the second message using the base private key 308. The second encrypted and signed message may further be transmitted from the asset application 204a to the mobile application 206a over the established datalink. The datalink may be established either using BLE, internet, or NFC.
[061] Once the message is transmitted to the mobile application 206a, the mobile application 206a may further verify the second message using the base public key 310. The mobile application 206a may further decrypt the second message using one of the main private key 408 or the additional private key 504 in response to the verification.
[062] Referring now to FIG. 8, a block diagram for Smartphone-to-Smartphone (S2S) secure data transfer is illustrated, in accordance with an embodiment. The block diagram may include a sender mobile application 802 that may be installed on the primary smartphone of the primary user, and a receiver mobile application 804 that may be installed on a secondary smartphone of the secondary user. In order to initiate the S2S secure data transfer, the sender mobile application 802 may generate a symmetric passkey. The receiver mobile application 804 may obtain the generated symmetric passkey from the sender mobile application 802. It may be noted that, the symmetric passkey may be obtained by the receiver mobile application 804 in a similar manner as one person securely shares one time password (OTP) with another person.
[063] Further, the sender mobile application 802 may encrypt the S2S data to generate an encrypted message using the symmetric passcode. The encrypted message may further be transmitted to the receiver mobile application 804 over the established datalink. The receiver mobile application 804 may further decrypt the encrypted message using the symmetric passcode and obtained a decrypted message in a from of third message.
[064] Referring now to FIG. 9, a block diagram for generating additional key via mobile application of primary user is illustrated, in accordance with an embodiment. For the generation of the additional key via the mobile application 206a of the primary user (for example, by the asset owner), the mobile application 206a may be required to have the main private key 408 and the base public key 310 stored in the storage 410. Further, the asset application 204a may be required to have the base private key 308 and the main public key 406.
[065] When the secondary user may request to generate the additional key using the mobile application 206a, a set of additional key objects 502 may be created. The set of additional key objects 502 may include an additional private key 504, an additional public key 506, an additional permission list 508, and an additional metadata 510. It may be noted that, the set of additional key objects 502 may be stored in the storage 410 of the mobile application 206a.
[066] Further, the additional public key 506, the additional permission list 508, and the additional metadata 510 may be sent to the asset application 204a via the S2A secure data transfer process as already discussed above in conjunction with FIG. 6. The data that is being transmitted may be signed using the main private key 408 and further be encrypted with the base public key 310.
[067] The asset application 204a may further decrypt and verify the data, and then stores the data (for example, the additional public key 506 and the additional permission list 508) into the storage 314. The asset application 204a may further send the additional key metadata 510 to the server application 202a. It may be noted that, after successfully sending the data to the asset application 204a, the additional public key may be deleted from the mobile application 206a in order to avoid data tempering or data compromising.
[068] Referring now to FIG. 10, a block diagram for sharing additional key with secondary smartphone is illustrated, in accordance with an embodiment. The block diagram may include the sender mobile application 802 that may be installed on the primary smartphone of the primary user, and the receiver mobile application 804 that may be installed on the secondary smartphone of the secondary user. For the additional key to be shared with the secondary smartphone, the sender mobile application 802 must have the additional private key 504, the additional permission list 508, and the base public key 310 within a storage 410a. Moreover, the sender mobile application 802 and the receiver mobile application 804 must have exchanged the passkey that is used in S2S data exchange technique.
[069] The sender mobile application 802 may send a bundle of data that includes the additional private key 504, the additional permission list 508, and the base public key 310 to the receiver mobile application 804. It may be noted that, the transmission of data may take place over the S2S secure data transfer technique. The S2S secure data transfer technique is already explained in conjunction with FIG. 8.
[070] The receiver mobile application 804 may receive the data and stores into a database 410b. In some embodiments, the base public key 310 may be used with A2S secure data transfer and the additional private key 504 may be used with S2A secure data transfer. The key generation device 102 may refer the additional permission list 508 in making access grant or deny decision.
[071] Referring now to FIG. 11, a block diagram for revoking additional key is illustrated, in accordance with an embodiment. Once the additional key is shared with one of the asset or the secondary smartphone, the additional key may be revoked to avoid data tempering. For the additional key to be revoked, the mobile application 206a may be required to have the base public key 310, the main private key 408, and the additional key metadata 510.
[072] Further, the primary user may request to revoke the additional key corresponding to the additional key metadata 510. Additionally, a revoke message may be sent to the asset application 204a via the S2A data transfer. The asset application 204a may receive the revoke request, validates the revoke request with the main private key 408 and then deletes the additional public key 506 and the associated permission list 508 the from storage 314.
[073] The asset application 204a may further sends the revoked message to the server application 202a. Finally, the server application 202a may delete the additional key metadata 510 from the storage 302.
[074] Referring now to FIG. 12, a block diagram for establishing a trusted location-based service context between asset and iPhone is illustrated, in accordance with an embodiment. Apple, the manufacturer of iOS-based smartphones, has provided Nearby Interaction (NI) framework specification for ultra-wideband (UWB) accessory manufacturers. Here, the asset may act as the UWB accessory with the iPhone for establishing the trusted location-based service context.
[075] The mobile application 206a may be required to have the base public key 310 and one of the main private key 408 or the additional private key 504 stored in the storage 410. Additionally, the asset application 204a of the asset 204 may be required to have the base private key 308 and one of the main public key 406 or the additional public key 506 stored in the storage 314. A datalink may be established between the asset application 204a and the mobile application 206a either using BLE or Internet or NFC.
[076] The asset application 204a may create a unique passcode along with NI accessory configuration data and may further sends the unique passcode to the smartphone. It may be noted that, the data may be transferred using A2S secure data transfer technique. Further, the mobile application 206a may receive the passcode along with NI accessory configuration data from asset 204. At this point asset authentication failure exception may trigger.
[077] Further, the mobile application 206a may create NI shareable configuration data and then send that to the asset 204 along with the same passcode received from the asset 204. The data may be transferred using the S2A secure data transfer technique. The asset application 204a may receive the passcode and NI shareable configuration data from the smartphone. The received passcode may be matched. At this point, the smartphone authentication failure exception may trigger. Furthermore, a two-way NI session may starts thereby establishing the trusted location-based service context with the UWB based distance ranging and angle of arrival (AoA).
[078] Referring now to FIG. 13, a flowchart of a method for generating and managing keys for smart device based keyless access to an asset is illustrated, in accordance with an embodiment. At step 1302, a base key associated with an asset and a base key metadata may be generated. The base key may include a base private key and a base public key.
[079] At step 1304, a main key and a main key metadata may be generated. The main key may be associated with the asset and a first smart device of a primary user. In some embodiments, the first smart device may be a smartphone and the primary user may be the asset owner. The main key may include a main private key and a main public key.
[080] At step 1306, a base permission list may be retrieved from the asset. In some embodiments, the base permission list may be generated automatically based on asset specification data prestored in the key generation device 102.
[081] At step 1308, the base private key, the main public key, and a base permission list may be shared with the asset. At step 1310, the base public key, the main private key, and the base permission list may be shared with the first smart device. This is already explained in conjunction with FIG. 3 and FIG. 4.
[082] Referring now to FIG. 14, a flowchart of a method for generating additional key is illustrated, in accordance with an embodiment. At step 1402, an additional key and an additional metadata may be generated. The additional key may be associated with the asset and a second smart device of a secondary user. In some embodiments, the second smart device may be a secondary smartphone and the secondary user may be a user other than asset owner. The additional key may include an additional private key and an additional public key.
[083] At step 1404, the additional permission list may be received. In some embodiments, the additional permission list may be generated, via the first smart device, by the primary user. It may be noted that, the additional permission list may be a subset of the base permission list.
[084] At step 1406, the additional public key, the additional metadata and the additional permission list may be shared with the asset. At step 1408, the additional private key, the additional permission list, and the base public key may be shared with the second smart device. The additional private key may enable the secondary user, via the second smart device, to gain keyless access to the asset in compliance with the additional permission list. This is already explained in conjunction with FIG. 9 and FIG. 10.
[085] Referring now to FIG. 15, a flowchart of a method for sharing additional key with asset, in accordance with an embodiment. At step 1502, a data may be signed using the main private key. The data may include the additional public key, the additional metadata, and the additional permission list.
[086] At step 1504, the data may be encrypted with the base public key. Further, at step 1506, the data may be decrypted and verified, by the asset. Once the data get verified, then at step 1508, the data may be stored in an internal storage. And, at step 1510, the additional metadata may be sent to a server by the asset. The complete process of sharing the additional key with the asset is already discussed in conjunction with FIG. 9.
[087] Referring now to FIG. 16, a flowchart of a method for sending and receiving a first message from first smart device to asset is illustrated, in accordance with an embodiment. In some embodiments, the first message may be transmitted from the primary smartphone i.e., asset owner smartphone to the asset. The transferring of first message from the smartphone to the asset may also be referred as S2A secure data transfer. At step 1602, a first message may be sent from the first smart device to the asset. For sending the first message, at step 1604, the first message may be encrypted using the base public key. Further, at step 1606, the first message may be signed using the main private key in response to encrypt the first message.
[088] Once the first message is sent to the asset, then at step 1608, the first message may be received by the asset. For receiving the first message, at step 1610, the first message may be verified using the main public key. Further, at step 1612, the first message may be decrypted using the base private key in response to verify the first message. The complete process of S2A secure data transfer is already explained in conjunction with FIG. 6.
[089] Referring now to FIG. 17, a flowchart of a method for sending and receiving a first message from second smart device to asset is illustrated, in accordance with an embodiment. At step 1702, the first message may be sent from the second smart device to the asset. For example, the first message may be sent from the secondary smartphone associated with a user other than asset owner to the asset. For the first message to be transferred from second smart device, at step 1704, the first message may be encrypted using the base public key. Further at step 1706, the first message may be signed using the additional private key in response to encrypt the first message.
[090] Once the first message is sent to the asset, then at step 1708, the first message may be received by the asset. For the first message to be received, at step 1710, the first message may be verified using the additional public key. Further, at step 1712, the first message may be decrypted using the base private key in response to verify the first message.
[091] Referring now to FIG. 18, a flowchart of a method for sending and receiving a second message from asset to first smart device is illustrated, in accordance with an embodiment. In some embodiments, the second message may be transmitted from the asset to the primary smartphone i.e., the smartphone associated with the asset owner. The transferring of second message from the asset to the smartphone may also be referred as A2S secure data transfer. At step 1802, the second message may be transferred from the asset to the first smart device. For the transfer of the second message, at step 1804, the second message may be encrypted using the main public key. Further at step 1806, the second message may be signed using the base private key in response to encrypt the second message.
[092] Once the second message is sent to the first smart device, then at step 1808, the second message may be received by the first smart device. For the second message to be received by the first smart device, at step 1810, the second message may be verified using the base public key. Further at step 1812, the second message may be decrypted using the main private key in response to verify the second message. The complete process of A2S secure data transfer is already explained in conjunction with FIG. 7.
[093] Referring now to FIG. 19, a flowchart of a method for sending and receiving a second message from asset to second smart device is illustrated, in accordance with an embodiment. At step 1902, the second message may be transferred from the asset to the second smart device. For the transfer of the second message, at step 1904, the second message may be encrypted using the additional public key. Further at step 1906, the second message may be signed using the base private key in response to encrypt the second message.
[094] Once the second message is sent to the second smart device, then at step 1908, the second message may be received by the second smart device. For the second message to be received by the second smart device, at step 1910, the second message may be verified using the base public key. Further at step 1912, the second message may be decrypted using the main private key in response to verify the second message.
[095] Referring now to FIG. 20, a flowchart of a method for exchanging a third message between first smart device and second smart device is illustrated, in accordance with an embodiment. In some embodiments, the first smart device may be associated with the primary user (for example, the asset owner) and the second smart device may be associated with the secondary user (for example, the user other than the asset owner). At step 2002, the third message may be exchanged between the first smart device and the second smart device. In some embodiments, the exchanging of the third message between the first smart device and the second smart device may also be referred as S2S secure data transfer. For the third message to be exchanged, at step 2004, a symmetric passkey may be generated. Further, at step 2006, the third message may be encrypted using the symmetric passkey to generate an encrypted message. The third message may include the base public key, the additional private key, and the additional permission list.
[096] At step 2008, the encrypted message may be transmitted to the second smart device. Further, at step 2010, the encrypted message may be received by the second smart device. Then, at step 2012, the encrypted message may be encrypted using the symmetric passkey. The complete process of S2S secure data transfer is already explained in conjunction with FIG. 8.
[097] As will be appreciated by those skilled in the art, the techniques described in the various embodiments discussed above are not routine, or conventional, or well understood in the art. The techniques discussed above provide for key generation for smart device based keyless access to assets. Further, the techniques may enable the asset owner to use the smartphone with main key to generate as many additional keys with customized access controls as required and securely share them with others. The keys may be generated using the state-of-the-art asymmetric encryption technique providing security options much beyond what a physical key may provide. In case if the smartphone with main key is lost or compromised, then the main key may be renewed using the server application. Further, the asset owner may revoke the additional keys that is shared with users other than asset owner using the owner smartphone’s mobile application. The additional key may also be revoked either through the asset application or using the server application.
[098] The disclosed techniques may further be used in establishing the trusted location-based service context between the asset and the iOS-based smartphone with UWB. The techniques may enable the existing connected asset systems extend to keyless access offerings with the key generation and sharing methods. The key generation and sharing methods as discussed above may be applied to various applicable use case scenarios, such as, a vehicle, an equipment, a machinery, an electronic safe, a self-storage, a building, etc.
[099] The techniques lay a foundation for building other value-added platforms and solutions built upon keyless access. For example, a global platform for key generation and sharing for integrated asset management solutions from various providers encompassing vehicle fleet management solutions, electric vehicle (EV) charging stations, parking garages, drive-through services, and the like.
[0100] Further, the key generation and sharing methods of the present disclosure may be integrated with or applied to a variety of connected asset solution offerings. For example, an asset original equipment manufacturer (OEM) provided connected asset solution where the asset is sold to and owned by an individual and that individual expects to have complete control over additional key generation and sharing. By way of another example, in asset renting solutions the connected asset may be used by different individuals but at non-overlapping duration where at server-side the additional keys with constrained permissions may be created for the individuals.
[0101] In light of the above-mentioned advantages and the technical advancements provided by the disclosed method and system, the claimed steps as discussed above are not routine, conventional, or well understood in the art, as the claimed steps enable the following solutions to the existing problems in conventional technologies. Further, the claimed steps clearly bring an improvement in the functioning of the device itself as the claimed steps provide a technical solution to a technical problem.
[0102] As will be also appreciated, the above-described techniques may take the form of computer or controller implemented processes and apparatuses for practicing those processes. The disclosure can also be embodied in the form of computer program code containing instructions embodied in tangible media, such as floppy diskettes, solid state drives, CD-ROMs, hard drives, or any other computer-readable storage medium, wherein, when the computer program code is loaded into and executed by a computer or controller, the computer becomes an apparatus for practicing the invention. The disclosure may also be embodied in the form of computer program code or signal, for example, whether stored in a storage medium, loaded into and/or executed by a computer or controller, or transmitted over some transmission medium, such as over electrical wiring or cabling, through fiber optics, or via electromagnetic radiation, wherein, when the computer program code is loaded into and executed by a computer, the computer becomes an apparatus for practicing the invention. When implemented on a general-purpose microprocessor, the computer program code segments configure the microprocessor to create specific logic circuits.
[0103] The disclosed methods and systems may be implemented on a conventional or a general-purpose computer system, such as a personal computer (PC) or server computer. Referring now to FIG. 21, an exemplary computing system 2100 that may be employed to implement processing functionality for various embodiments (e.g., as a SIMD device, client device, server device, one or more processors, or the like) is illustrated. Those skilled in the relevant art will also recognize how to implement the invention using other computer systems or architectures. The computing system 2100 may represent, for example, a user device such as a desktop, a laptop, a mobile phone, personal entertainment device, DVR, and so on, or any other type of special or general-purpose computing device as may be desirable or appropriate for a given application or environment. The computing system 2100 may include one or more processors, such as a processor 2102 that may be implemented using a general or special purpose processing engine such as, for example, a microprocessor, microcontroller or other control logic. In this example, the processor 2102 is connected to a bus 2104 or other communication medium. In some embodiments, the processor 2102 may be an Artificial Intelligence (AI) processor, which may be implemented as a Tensor Processing Unit (TPU), or a graphical processor unit, or a custom programmable solution Field-Programmable Gate Array (FPGA).
[0104] The computing system 2100 may also include a memory 2106 (main memory), for example, Random Access Memory (RAM) or other dynamic memory, for storing information and instructions to be executed by the processor 2102. The memory 2106 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by the processor 2102. The computing system 2100 may likewise include a read only memory (“ROM”) or other static storage device coupled to bus 2104 for storing static information and instructions for the processor 2102.
[0105] The computing system 2100 may also include storage devices 2108, which may include, for example, a media drive 2110 and a removable storage interface. The media drive 2110 may include a drive or other mechanism to support fixed or removable storage media, such as a hard disk drive, a floppy disk drive, a magnetic tape drive, an SD card port, a USB port, a micro USB, an optical disk drive, a CD or DVD drive (R or RW), or other removable or fixed media drive. A storage media 2112 may include, for example, a hard disk, magnetic tape, flash drive, or other fixed or removable medium that is read by and written to by the media drive 2110. As these examples illustrate, the storage media 2112 may include a computer-readable storage medium having stored therein particular computer software or data.
[0106] In alternative embodiments, the storage devices 2108 may include other similar instrumentalities for allowing computer programs or other instructions or data to be loaded into the computing system 2100. Such instrumentalities may include, for example, a removable storage unit 2114 and a storage unit interface 2116, such as a program cartridge and cartridge interface, a removable memory (for example, a flash memory or other removable memory module) and memory slot, and other removable storage units and interfaces that allow software and data to be transferred from the removable storage unit 2114 to the computing system 2100.
[0107] The computing system 2100 may also include a communications interface 2118. The communications interface 2118 may be used to allow software and data to be transferred between the computing system 2100 and external devices. Examples of the communications interface 2118 may include a network interface (such as an Ethernet or other NIC card), a communications port (such as for example, a USB port, a micro USB port), Near field Communication (NFC), etc. Software and data transferred via the communications interface 2118 are in the form of signals which may be electronic, electromagnetic, optical, or other signals capable of being received by the communications interface 2118. These signals are provided to the communications interface 2118 via a channel 2120. The channel 2120 may carry signals and may be implemented using a wireless medium, wire or cable, fiber optics, or other communications medium. Some examples of the channel 2120 may include a phone line, a cellular phone link, an RF link, a Bluetooth link, a network interface, a local or wide area network, and other communications channels.
[0108] The computing system 2100 may further include Input/Output (I/O) devices 2122. Examples may include, but are not limited to a display, keypad, microphone, audio speakers, vibrating motor, LED lights, etc. The I/O devices 2122 may receive input from a user and also display an output of the computation performed by the processor 2102. In this document, the terms “computer program product” and “computer-readable medium” may be used generally to refer to media such as, for example, the memory 2106, the storage devices 2108, the removable storage unit 2114, or signal(s) on the channel 2120. These and other forms of computer-readable media may be involved in providing one or more sequences of one or more instructions to the processor 2102 for execution. Such instructions, generally referred to as “computer program code” (which may be grouped in the form of computer programs or other groupings), when executed, enable the computing system 2100 to perform features or functions of embodiments of the present invention.
[0109] In an embodiment where the elements are implemented using software, the software may be stored in a computer-readable medium and loaded into the computing system 2100 using, for example, the removable storage unit 2114, the media drive 2110 or the communications interface 2118. The control logic (in this example, software instructions or computer program code), when executed by the processor 2102, causes the processor 2102 to perform the functions of the invention as described herein.
[0110] It will be appreciated that, for clarity purposes, the above description has described embodiments of the invention with reference to different functional units and processors. However, it will be apparent that any suitable distribution of functionality between different functional units, processors or domains may be used without detracting from the invention. For example, functionality illustrated to be performed by separate processors or controllers may be performed by the same processor or controller. Hence, references to specific functional units are only to be seen as references to suitable means for providing the described functionality, rather than indicative of a strict logical or physical structure or organization.
[0111] Although the present invention has been described in connection with some embodiments, it is not intended to be limited to the specific form set forth herein. Rather, the scope of the present invention is limited only by the claims. Additionally, although a feature may appear to be described in connection with particular embodiments, one skilled in the art would recognize that various features of the described embodiments may be combined in accordance with the invention.
[0112] Furthermore, although individually listed, a plurality of means, elements or process steps may be implemented by, for example, a single unit or processor. Additionally, although individual features may be included in different claims, these may possibly be advantageously combined, and the inclusion in different claims does not imply that a combination of features is not feasible and/or advantageous. Also, the inclusion of a feature in one category of claims does not imply a limitation to this category, but rather the feature may be equally applicable to other claim categories, as appropriate.

CLAIMS

We claim:

1. A method of generation and management of keys for smart device based keyless access to an asset (204), the method comprising:
generating (1302), via a key generation device (102), a base key associated with an asset (204) and a base key metadata (312), wherein the base key comprises a base private key (308) and a base public key (310);
generating (1304), by the key generation device (102), a main key and a main key metadata (404), wherein the main key is associated with the asset (204) and a first smart device of a primary user, and wherein the main key comprises a main private key (408) and a main public key (406);
sharing, via the key generation device (102), of:
the base private key (308), the main public key (310), and a base permission list (304) with the asset (204); and
the base public key (308), the main private key (406), and the base permission list (304) with the first smart device; and
wherein the main private key (408) enables the primary user, via the first smart device, to gain keyless access to the asset (204).

2. The method as claimed in claim 1, comprising generating (1402), via the key generation device (102), an additional key and an additional key metadata (510), wherein the additional key is associated with the asset (204) and a second smart device of a secondary user, and wherein the additional key comprises an additional private key (504) and an additional public key (506).

3. The method as claimed in claim 2, comprising sharing of:
the additional public key (506), the additional key metadata (510) and an additional permission list (508) with the asset (204);
the additional private key (504), the additional permission list (508), and the base public key (310) with the second smart device; and
wherein the additional private key (504) enables the secondary user, via the second smart device, to gain keyless access to the asset (204) in compliance with the additional permission list (508).

4. The method as claimed in claim 3, wherein sharing (1406) the additional public key (504), the additional key metadata (510) and the additional permission list (508) with the asset (204) comprises:
signing (1502) a data comprising the additional public key (506), the additional key metadata (510), and the additional permission list (508), using the main private key (408);
encrypting (1504) the data with the base public key (310);
decrypting and verifying (1506), by the asset (204), the data;
storing (1508), by the asset (204), the data in an internal storage; and
sending (1510), by the asset (204), the additional key metadata (510) to a server.

5. The method as claimed in claim 2, comprising receiving (1404) the additional permission list (508), wherein the additional permission list (508) is generated, via the first smart device, by the primary user, wherein the additional permission list (508) is a subset of the base permission list (304), and wherein the base permission list (304) is retrieved from the asset (204).

6. The method as claimed in claim 2, comprising:
sending a first message from one of the first smart device or the second smart device to the asset (204), wherein sending the first message comprises:
encrypting the first message using the base public key (310); and
signing the first message using one of the main private key (408) or the additional private key in response to encrypting the first message; and
receiving the first message by the asset (204), wherein receiving comprises:
verifying the first message using one of the main public key (406) or the additional public key (506); and
decrypting the first message using the base private key (308) in response to verifying the first message.

7. The method as claimed in claim 6, comprising:
sending a second message from the asset (204) to one of the first smart device or the second smart device, wherein sending the second message comprises:
encrypting the second message using the main public key (406) or the additional public key (506); and
signing the second message using the base private key (308) in response to encrypting the second message; and
receiving the second message by one of the first smart device or the second smart device, wherein receiving comprises:
verifying the second message using the base public key (310); and
decrypting the second message using one of the main private key (408) or the additional private key (504), in response to verifying the second message.

8. The method as claimed in claim 2, comprising exchanging (2002) a third message between the first smart device and the second smart device, wherein exchanging (2002) at least one third message comprises:
generating (2004), by the first smart device, a symmetric passkey;
encrypting (2006), by the first smart device, the third message using the symmetric passkey to generate an encrypted message, wherein the third message comprises the base public key, the additional private key, and the additional permission list;
transmitting (2008), by the first smart device, the encrypted message to the second smart device;
receiving (2010), by the second smart device, the encrypted message; and
decrypting (2012), by the second smart device, the encrypted message using the symmetric passkey.

9. A system (100) of generation and management of keys for smart device based keyless access to an asset (204), the system (100) comprising:
a processor (104) and a memory (106) communicatively coupled to the processor (104), wherein the memory (106) stores processor-executable instructions, which, on execution, causes the processor (104) to:
generate a base key associated with an asset (204) and a base key metadata (312), wherein the base key comprises a base private key (308) and a base public key (310);
generate a main key and a main key metadata (404), wherein the main key is associated with the asset (204) and a first smart device of a primary user, and wherein the main key comprises a main private key (408) and a main public key (406);
share of:
the base private key (308), the main public key (310), and a base permission list (304) with the asset (204); and
the base public key (308), the main private key (406), and the base permission list (304) with the first smart device; and
wherein the main private key (408) enables the primary user, via the first smart device, to gain keyless access to the asset (204).

10. The system as claimed in claim 9, wherein the processor instructions, on execution, cause the processor (104) to generate, via the key generation device (102), an additional key and an additional key metadata (510), wherein the additional key is associated with the asset (204) and a second smart device of a secondary user, and wherein the additional key comprises an additional private key (504) and an additional public key (506).

11. The system as claimed in claim 10, wherein the processor instructions, on execution, cause the processor (104) to share of:
the additional public key (506), the additional key metadata (510) and an additional permission list (508) with the asset (204);
the additional private key (504), the additional permission list (508), and the base public key (310) with the second smart device; and
wherein the additional private key (504) enables the secondary user, via the second smart device, to gain keyless access to the asset (204) in compliance with the additional permission list (508).

12. The system as claimed in claim 11, wherein to share the additional public key (504), the additional key metadata (510) and the additional permission list (508) with the asset (204), the processor instructions, on execution, cause the processor (104) to:
sign a data comprising the additional public key (506), the additional key metadata (510), and the additional permission list (508), using the main private key (408);
encrypt the data with the base public key (310);
decrypt and verify, by the asset (204), the data;
store, by the asset (204), the data in an internal storage; and
send, by the asset (204), the additional key metadata (510) to a server.

13. The system as claimed in claim 10, wherein the processor instructions, on execution, cause the processor (104) to receive the additional permission list (508), wherein the additional permission list (508) is generated, via the first smart device, by the primary user, wherein the additional permission list (508) is a subset of the base permission list (304), and wherein the base permission list (304) is retrieved from the asset (204).

14. The system as claimed in claim 10, wherein the processor instructions, on execution, cause the processor (104) to:
send a first message from one of the first smart device or the second smart device to the asset (204), wherein to send the first message, the processor instructions, on execution, cause the processor (104) to:
encrypt the first message using the base public key (310); and
sign the first message using one of the main private key (408) or the additional private key in response to encrypting the first message; and
receive the first message by the asset (204), wherein to receive the first message by the asset, the processor instructions, on execution, cause the processor (104) to:
verify the first message using one of the main public key (406) or the additional public key (506); and
decrypt the first message using the base private key (308) in response to verifying the first message.

15. The system as claimed in claim 14, wherein the processor instructions, on execution, cause the processor (104) to:
send a second message from the asset (204) to one of the first smart device or the second smart device, wherein to send the second message, the processor instructions, on execution, cause the processor (104) to:
encrypt the second message using the main public key (406) or the additional public key (506); and
sign the second message using the base private key (308) in response to encryption of the second message; and
receive the second message by one of the first smart device or the second smart device, wherein to receive the second message, the processor instructions, on execution, cause the processor (104) to:
verify the second message using the base public key (310); and
decrypt the second message using one of the main private key (408) or the additional private key (504), in response to verification of the second message.

16. The system as claimed in claim 10, wherein the processor instructions, on execution, cause the processor (104) to exchange a third message between the first smart device and the second smart device, and wherein to exchange at least one third message, the processor instructions, on execution, cause the processor (104) to:
generate, by the first smart device, a symmetric passkey;
encrypt, by the first smart device, the third message using the symmetric passkey to generate an encrypted message, wherein the third message comprises the base public key, the additional private key, and the additional permission list;
transmit, by the first smart device, the encrypted message to the second smart device;
receive, by the second smart device, the encrypted message; and
decrypt, by the second smart device, the encrypted message using the symmetric passkey.