SYSTEMS AND METHODS FOR BLOCK DATA SECURITY FOR DIGITAL COMMUNICATIONS FROM A PHYSICAL DEVICE
Verifying payloads for vending machines, wherein a consumer may purchase a product on their mobile computing device, ping a minted computing device associated with the vending machine, and the minted computing device authorizes the vending machine to dispense the object.
Latest VITRO TECHNOLOGY CORPORATION Patents:
Examples of the present disclosure are related to systems and methods for physical computing device to transmit authenticated data blocks, wherein the blocks and the enclosed data is secured regardless of the method of communication. More specifically, embodiments are directed towards authenticated data used in secure transactions, authenticated control of devices and proven data origin that can be communicated as blocks over unsecured channels over different types of networks, wherein a meter that measures and transmits quantities at specific intervals, such as a power meter, water meter, etc., wherein measured quantities are authenticated to have originated at a specific meter, wherein a household may be billed for the measured consumption by the public utility or service provider.
BackgroundBlockchain is a list of records, called blocks, which are linked to cryptology. Each block is signed with a cryptographic hash of the data. A blockchain is formed by adding the hash of the previous block to the data of the current block then hashing and signing the combined data payload. A single block or a blockchain prohibits modification of any payload data via the cryptographic hash. Conventionally, blockchain technology is utilized for digital wallets based on public and private keys. A digital wallet may have multiple public and private key pairs and are used to spend cryptocurrency. However, digital wallets are decentralized and are not tied to specific hardware. Situations arise where it is desirable to verify and audit transactions associated with a specific hardware element utilizing the construction of data into blocks.
Additionally, communications security is difficult to enforce in across the wide spectrum of wired and wireless transmissions. Transport Layer Security (TLS) is generally used to secure data in motion. However, TLS may be unavailable as data transits multiple networks in a low bandwidth environment. Payload Layer Security (PLS) assures that data is transported in blocks, and that each block has proof of origin and proof of integrity incorporated with the payload data. In addition, the authentication of the block at a “broker” enforces access rights to the secured data. Each request of the data from a secured block is authenticated by the broker, serving data only to authorized users and applications while building an audit record of block access by user and by application.
Managing the authorization of payment from vending machines requires the use of multiple networks due to bandwidth constraints. Vending machines can be located in remote areas (e.g. basements, stairwells) where local or secondary networks are the only connectivity option.
Accordingly, needs exist for more effective and efficient systems and methods for vending machines that are configured to receive commands over a public broadcast network and not act as a controller for the transaction. The vending machine is only configured to receive a protected payload from a trusted source, wherein the protected payload is configured to operate the vending machine over the public broadcast network
Furthermore, conventional methods of transport layer security to transmit data over networks rely on securing communication channels. More specifically, once a communications channels are secured, any data transferred through the communications channels between a first device and a second device may also be secured. However, to secure a communications channel over the transport layer requires multiple communications between the first device and the second device to secure the channel. These multiple communications before the channel is secure can lead to data leaks. For example, to secure the transport layer, a public key is utilized to secure the channel. Yet, this public key could be used for a quantum attack of the channel where a private key could be derived.
Accordingly, needs exist for payload level security, wherein the data being transmitted between the first device and the second device is secured. This can lead to secured data being transmitted over an unsecure channel.
SUMMARYEmbodiments are configured to mint, establish, and permanently allocate an address for an edge server based on unique key generation, wherein the key generation is configured to create a private—public key pair. Embodiments may be configured to tie virtual financial micro transactions with physical equipment, wherein the physical equipment may be a vending machine, POS terminal, metering device, etc. that is configured to provide goods or services. More specifically, embodiments are directed towards creating payload level security to replace existing transport layer security. For example, conventional methods utilize systems that create a secure channel or “pipe” to send data. Utilizing conventional methods, as long as the channel or “pipe” is secure, then the data communicated within the channel or “pipe” is clean. However, if the channel or “pipe” becomes compromised, then all data communicated within the channel becomes comprised, which can occur without being noticed. Current embodiments protect the payload itself by encrypting or “bottling” the payload into blocks. Because the payload itself is a block, then the protected payload is able to be communicated over any channel. Embodiments may include an edge server, public network, mobile computing device, private network, a POS device, and transaction server. Other embodiments may include a metering device, edge server, router, and broker.
In implementations, the key pair may be generated upon initialization of an edge server, wherein the edge server may be configured to communicate over different types of networks, such as LoRa. The edge server is minted with a key pair or other unique identifier, wherein the minting of the server occurs when the edge server is booted for a first time. The key pair may include a private key and a public key, wherein the key pair may be utilized to protect a payload. To this end, the key pair may be generated during a Root of Trust process, when the server's firmware, operating system, etc. is initially loaded and created. The key pair may be utilized as a token for supply-chain billings, payments, auditing, authenticating data, etc. In embodiments, the edge server may be configured to control the vending machine by sending and receiving signed payloads with the token, and used to verify payloads directly to see if the payloads are authentic and should be trusted. To this end, the edge server may be configured to receive transaction data from the transaction servers, protect the payload, and transmit the protected payload to the POS device over a public network.
Utilizing the key pair or token, a digital certificate may be issued for the edge server, wherein the digital certificate may enable the edge server to be registered with a cloud computing service provider. In embodiments, to receive the digital certificate, the edge server may transmit a certificate request with the generated public key to a trusted third party (TTP), such as Digicert. In embodiments, the edge server may only send the public key a single time to the trusted third party, which may limit the amounts of time the edge server transmits secured data. The trusted third party may respond to the certificate request with a data associated with the digital certificate that is encoded based on the public key. The data to create the digital certificate may only be decrypted utilizing the private key stored only on the edge server without the private key being communicated from the edge server. This may enable the transmitted payload from the edge servers to be protected, allowing the protected payload to be transmitted over public networks or other unsecure networks. Specifically, because the TTP has the digital certificate and/or public key, the TTP may verify a hash associated with the protected payload, to determine that the received protected payload is secure.
The public network may be a long range radio modulation technique (LoRa). The public network may any low power, wide area networking protocol design to wirelessly connect devices over low frequency bands. In embodiments, the low frequency bands may be 900 MHz. Due to the low frequency bands, data transmitted over the public network may have good building penetration and also allow for long distance data transmission.
The mobile computing device may be a smart phone, smart watch, laptop, gaming system, etc. with a hardware processor, user interface device, and communications device. The mobile computing device may be configured to receive commands from a user via the user interface device. The commands may be associated with purchasing an item or service from the POS device. Responsive to receiving the commands, the mobile computing device may transmit data associated with the commands to the transaction server over a private network.
The private network may be a wide area network (WAN) that extends over a large geographical distance. The private network may be a wireless communications network, digital radio, or cellular network operating over CDMA, GSM, etc. In embodiments, the private network may be operated by telecommunications providers. One skilled in the art may appreciate that the private network may include a wireless local area network, such as a Wi-Fi network, which may be utilized to relay data to the private network.
The POS device may be a vending machine or a service providing machine, such as an AC unit, water fountain, water meter, gas meter, bathroom, etc. For example, the POS device may be configured to dispense items such as snacks, beverages, newspapers, alcohol, cigarettes, electronics, etc. In embodiments, the POS device may include a computing device that is a dummy device, wherein the dummy device is a vending multi-drop bus (MDB). The POS device may have a unique identifier, such as a QR-code, barcode, alphanumeric identifier, etc., which a user may enter into a graphical user interface on mobile computing device to select a good or service from the POS device. The computing device associated with the POS device may be configured to receive commands from the edge server over a wired, physical, public network to dispense items. In embodiments, the POS device may not directly communicate with the mobile computing device.
The transaction server may be a peer-to-peer, cloud based, mobile payment system. The transaction server may include digital wallets that are configured to receive payments for micro transactions or micropayments. For example, the transaction server may be associated with venmo, Amazon pay, cash app, etc. In embodiments, responsive to the mobile device scanning a QR-code associated with the POS device, and making a selection of goods or services offered from the POS device on the mobile computing device, data may be transmitted from the mobile computing device to the transaction server over the private network, wherein the data includes information associated with the selected goods or services. After receiving the data from the mobile computing device, the transaction server may encrypt a payload, and transmit the encrypted payload to the edge server to authenticate a command for the POS device over a public wireless network.
Responsive to the edge server authenticating the command via decrypting the encrypted payload, the edge server may communicate the authenticate command to the POS device over a public and physically wired network to dispense the good or service via MDB. In embodiments, the authenticated transmitted command from the transaction server may be authenticated via the key pair on the edge device. To this end, the authenticated command transmitted from the edge server may be protected payload.
In specific embodiments, to authenticate a command from the cloud server via the protected payload, the edge server may transmit the digital certificate to a remote service provider along with a request for computing services. The computing service provider may transmit the digital certificate to the trusted third party to authenticate the digital certificate. Responsive to authenticating the digital certificate, the edge server may be registered with the cloud computing service provider. Transactions between the transaction server and the edge server may be automatically updated into a ledger using blockchain technology, wherein the cloud computing service provider may receive protected payload from the edge server over unsecure and/or secure communications channels without transmitting the public key a second time because the payload transmitted from the edge server utilizes
These, and other, aspects of the invention will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings. The following description, while indicating various embodiments of the invention and numerous specific details thereof, is given by way of illustration and not of limitation. Many substitutions, modifications, additions or rearrangements may be made within the scope of the invention, and the invention includes all such substitutions, modifications, additions or rearrangements.
Non-limiting and non-exhaustive embodiments of the present invention are described with reference to the following figures, wherein like reference numerals refer to like parts throughout the various views unless otherwise specified.
Corresponding reference characters indicate corresponding components throughout the several views of the drawings. Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated relative to other elements to help improve understanding of various embodiments of the present disclosure. Also, common but well-understood elements that are useful or necessary in a commercially feasible embodiment are often not depicted in order to facilitate a less obstructed view of these various embodiments of the present disclosure.
DETAILED DESCRIPTIONIn the following description, numerous specific details are set forth in order to provide a thorough understanding of the present embodiments. It will be apparent, however, to one having ordinary skill in the art that the specific detail need not be employed to practice the present embodiments. In other instances, well-known materials or methods have not been described in detail in order to avoid obscuring the present embodiments.
Blockchain is a list of records, called blocks, which are linked to cryptology. Each block is signed with a cryptographic hash of the data. A blockchain is formed by adding the hash of the previous block to the data of the current block then hashing and signing the combined data payload. A single block or a blockchain prohibits modification of any payload data via the cryptographic hash. A digital wallet may have multiple public and private key pairs and are used to spend cryptocurrency. However, digital wallets are decentralized and are not tied to specific hardware. Embodiments may be configured to verify and audit transactions associated with a specific hardware element utilizing the construction of data into blocks, wherein a single hardware element autonomously creates a digital wallet upon startup that includes a private and public key.
Edge server 110 may be a computing device that is configured to provide an entry point into public network 120. Edge server 110 may be any type of computing device that is configured to automatically implement computing communications sequences over a network. Edge server 110 may be configured to request and utilize computing resources to implement a wide range or tasks. Additionally, edge server 110 may be configured to receive analog data from a metering device, and digitize the received analog data to be transmitted over a network. In implementations, edge server 110 may be configured to transmit protected data to POS device 150, and to receive data from transaction server 160.
Edge server 110 may include an initialization module, key pair generator, token module, certification module, block chain module.
The initialization module may be a hardware processing device that is configured to provide runtime services for the operating system and programs associated with Edge server 110. Initialization module may be configured to scan extensions of physical computing device's memory to determine if edge server 110 is powered on, has connectivity, what operating system is running, or any other initiation step.
The key pair generator may be a self-contained and isolated hardware processing device configured to determine a key pair including a public key and a private key responsive to initialization module initializing edge server 110. In implementations, the key pair generator may utilize elliptic-curve cryptography (ECC) or any other method to generate a key pair, which may be implemented in a just-in-time registration. The key pair generator may be configured to generate a single key pair responsive to initializing edge server 110 the first time. Utilizing the key pair, a digital certificate may be issued for the edge server 110, wherein the digital certificate may enable the edge server 110 to be registered with a cloud computing service provider, such as transaction server 160. In embodiments, to receive the digital certificate, edge server 110 may transmit a certificate request with the generated public key to a trusted third party (TTP), such as Digicert. In embodiments, edge server 110 may only transmit the public key to a TTP a single time. The trusted third party may respond to the certificate request with a data associated with the digital certificate that is encoded based on the public key. The data to create the digital certificate may only be decrypted utilizing the private key stored only on the edge server 110 without the private key being communicated from the edge server 110. This may enable any payload transmitted from the edge server 110 to be protected, enabling the protected payload to be transmitted over public network 120.
The token module may be a hardware memory device configured to store data associated with the generated key pair, such as the public and private key. In further implementations, token module may include a digital wallet that is configured to store cryptocurrencies that are tied to the generated key pair. The digital wallet may be utilized to protect payload for data transmitted to POS device 150.
The certification module may be a hardware processing and communication device that is configured to certify edge server 110 to other computing elements. In implementations, the certification module may be configured to transmit the public key associated with edge server 110 to a trusted third party. Responsive to transmitting the public key, edge server 110 may receive a digital certificate from the trusted third party, wherein the digital certificate is encrypted based on the public key.
The blockchain module may be a hardware processing and memory device configured to generate a blockchain ledger for edge server 110. The blockchain module may be configured to record and automatically update transactions between edge server 110 and POS device 150. In implementations, the blockchain module may receive a transaction request that may be posted on the ledger based on the public key from transaction server 160, which can be authenticated using the private key stored in the token module. Additionally, edge server 110 may transmit protected payload to POS device 150 to control the POS device 150 based on the private key stored within the token module. This may enable remote service providers to access the ledger to determine if payments for the POS device 150 are paid for auditing purposes.
Public network 120 may be a long range radio modulation technique (LoRa). Public network 120 may any low power, wide area networking protocol design to wirelessly connect devices over low frequency bands. In embodiments, the low frequency bands may be 900 MHz. Due to the low frequency bands, data transmitted over Public network 120 may have good building penetration and also allow for long distance data transmission. In embodiments, edge server 110 may be configured to transmit protected payload over public network 120 to POS device 150.
Mobile computing device 130 may be a smart phone, smart watch, laptop, gaming system, etc. with a hardware processor, user interface device, and communications device. Mobile computing device 130 may be configured to receive a unique identifier associated with the POS device 150 and commands from a user via the user interface device. The commands may be associated with purchasing an item or service from the POS device 150. Responsive to receiving the commands, Mobile computing device 130 may transmit data associated with the commands to the transaction server 160 over a private network 140.
Private network 140 may be a wide area network (WAN) that extends over a large geographical distance. Private network 140 may be a wireless communications network, digital radio, or cellular network operating over CDMA, GSM, etc. In embodiments, private network 140 may be operated by telecommunications providers. One skilled in the art may appreciate that private network 140 may include a wireless local area network, such as a Wi-Fi network, which may be utilized to relay data the private network 140.
The POS device 150 may be a vending machine or a service providing machine, such as an AC unit, water fountain, bathroom, etc. For example, POS device 150 may be configured to dispense items such as snacks, beverages, newspapers, alcohol, cigarettes, electronics, etc. Alternatively, POS device 150 may be an air conditioning unit or any other unit configured to give a user a service. In embodiments, POS device 150 may include a computing device that is a dummy device, wherein the dummy device is a vending multi-drop bus (MDB). POS device 150 may have a unique identifier, such as a QR-code, barcode, alphanumeric identifier, etc., which a user may enter into a graphical user interface on mobile computing device 130 to select a good or service from POS device 150. The computing device associated with POS device 150 may be configured to receive commands from the edge server 110 over the public network 120 to dispense items. In embodiments, POS device 150 may not directly communicate with the mobile computing device 150.
Transaction server 160 may be a peer-to-peer, cloud based, mobile payment system. Transaction server 160 may include digital wallets that are configured to receive payments for micro transactions or micropayments. For example, transaction server 160 may be associated with venom, Amazon pay, cash app, etc. In embodiments, responsive to the mobile computing device 130 scanning a QR-code associated with the POS device 150, be provided with a graphical user interface and making a selection of goods or services offered from the POS device 150, data may be transmitted from the mobile computing device 130 to the transaction server 160 over the private network 140, wherein the data includes information associated with the selected goods or services. In embodiments, after receiving the data from the mobile computing device 130 over the private network or a public network, the transaction server 160 may encrypt a payload associated with the transaction, and ping the edge server 110 to authenticate a command for the POS device 130 associated with the transaction. Responsive to the edge server 110 receiving the protected payload over the public network, the edge server 110 may decrypt the payload to authenticate the command the command. The edge server 110 may communicate the authenticate command to the POS device 150 over a wired, physical network to dispense the good or service via MDB. In embodiments, the authenticated transmitted command may be authenticated via the key pair on the edge server 220. To this end, the authenticated command and the encrypted data from the transaction server may be protected payload, which can be transmitted over public networks.
In some embodiments, method 200 may be implemented in one or more processing devices (e.g., a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a solid-state machine, and/or other mechanisms for electronically processing information). The one or more processing devices may include one or more devices executing some or all of the operations of method 200 in response to instructions stored electronically on an electronic storage medium. The one or more processing devices may include one or more devices configured through hardware, firmware, and/or software to be specifically designed for execution of one or more of the operations of method 200.
At operation 210, an edge server may be initialized and generate a private-public key pair. In embodiments, the edge server may generate the private-public key pair at initialization, and never transmit the private-key to another party. The edge server device may transmit the public key to a trusted third party a single time. This may be part of a certificate exchange for a root of trust procedure. The trusted third party may generate a digital certificate for the edge server based on the received public key. The digital certificate may indicate that the private key is stored remotely from the trusted third party. The trusted third party may decrypt the digital certificate based on the public key. The digital certificate may be received by the edge server, and can be decrypted based on the locally stored private key.
At operation 220, a user utilizing a mobile computing device may perform actions on a user interface of the mobile computing device to select goods and/or services from a POS device. The performed actions may include a unique identifier associated with the POS device and information associated with the selection of the goods and/or services.
At operation 230, the mobile computing device may transmit data associated with the unique identifier associated with the POS device and the information associated with the selection of the goods and/or services over a private network to a transaction server.
At operation 240, the transaction server may receive the data from the POS device, and create an encrypted payload. The encrypted payload may be transmitted to the edge server to authenticate the transmitted data received from the mobile computing device.
At operation 250, responsive to receiving the encrypted payload from the transaction server, the edge server may utilize the digital wallet and key pair to decrypt the encrypted and protected payload. The edge server may communicate the decrypted payload over a public and physical network to a POS device. In embodiments, the protected payload may be configured to remotely control the POS device.
At operation 260, the POS device may receive the decrypted payload over the public and physical network and dispense the goods and/or services associated with the protected payload.
At operation 270, responsive to the POS dispensing the goods, the POS device may transmit data to the edge server that the transaction has been completed. The edge server may encrypt the data, then transmit the protected payload to the transaction server to charge the mobile computing device for the transaction. A ledger associated with the edge server may then be updated based on the transaction utilizing data received from the edge server and the transaction server.
Metering device 310 may be any type of metering device that is configured to provide a good or service, and may record data at set intervals or responsive to a predetermined event taking place. For example, metering device 310 may be a water configured to determine how much water as flowed past the metering device 310 over intervals. In other embodiments, metering device 310 may be a vending machine that is configured to record data responsive to the vending machine performing a transaction. Metering device 310 may be configured to record the data, and directly transmit the data to edge server 110. In embodiments, metering device 310 may not encrypt the recorded data before transmitting the recorded data to edge server 110.
Edge server 110 may be a hardware processing device that is configured to provide runtime services for the operating system of edge server 110. Edge server 110 may be configured to generate a private-public key pair responsive to edge server 110 being initialized, such that the minting of edge server 110 is self-contained. In embodiments, the private key may be configured to be locally stored within edge server 110 and never transmitted to another device. The public key may be configured to be transmitted from edge server 110 to cloud computing server 320 a single time. The public key may be utilized to encrypt data transmitted from edge server 110 along with the digital signature of edge server 110 to cloud computing server 320. More specifically, edge server 110 may receive data from metering device, create a hash of the data, and digitally sign the has utilizing the private key to form a protected payload. The protected payload may then be transmitted to cloud computing server 320. Cloud computing server 110 may then utilize the locally stored public key to decrypted the protected payload. This may enable edge server 110 to transmit protected payload to cloud computing server 320, which can be utilized over unsecure networks.
Cloud computing server 320 may be an on-demand availability of computer resources, especially data storage and computing power, without direct active management by the user. Cloud computing server 320 may be configured to receive protected payload from edge server 110 and transmit corresponding unprotected data to third parties. Cloud computing server 320 may include a router 330 and broker 330.
Router 320 may be a hardware device that is configured to receive the public key from edge server 110, store the public key locally, and later receive the protected payload from edge server 110, wherein the protected payload includes blocks of data. Responsive to receiving the protecting payload, router 320 may check the hash associated with the protected payload without receiving the public key to determine that the blocks of data are correct, and check the signature associated with the protected payload to verify that the edge server sent the protected payload. This may enable router 320 to authenticate the data associated with the protected payload and verify a signature associated with edge server 110. Responsive to authenticating the data and verify that edge server 110 sent the protected payload, the router may store the data associated with the protected payload at a location associated with the edge server 110, such that the data can later be accessed by broker 330.
Broker 330 may be a hardware device that manages the use, performance, and delivery of cloud services associated with cloud computing server 320. In embodiments, broker 330 may be configured to authenticate third party computing device 350 as a computing device or application authorized to receive data associated with edge server 110, fetch the blocks of data associated with edge server 110, unwrap the data associated with the blocks, and transmit the raw data associated with the protected payload to the third party computing device 350 after authenticating third party computing device 350.
In some embodiments, method 400 may be implemented in one or more processing devices (e.g., a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a solid-state machine, and/or other mechanisms for electronically processing information). The one or more processing devices may include one or more devices executing some or all of the operations of method 200 in response to instructions stored electronically on an electronic storage medium. The one or more processing devices may include one or more devices configured through hardware, firmware, and/or software to be specifically designed for execution of one or more of the operations of method 400.
At operation 410, an edge server may be initialized and generate a private-public key pair. In embodiments, the edge server may generate the private-public key pair at initialization, and never transmit the private-key to another party.
At operation 420, the edge server may transmit the public key to a router a single time.
At operation 430, the edge server may receive data from a metering device or other type of computing system. For example, the metering device may indicate a number of KWs have been utilized from an appliance, whether a valve is opened or close, images, etc.
At operation 440, the edge server may create a hash of the data from the metering device utilizing the private key, and transmit a digitally signed hash and data as a protected payload to the router. The edge server may transmit the digitally signed hash without transmitting the public key.
At operation 450, the router may receive the digitally signed hash and data. Responsive to receiving the digitally signed hash, the router may verify the signed hash and the digital signature utilizing the locally stored public key. Next, the router may store the data associated with the protected payload.
At operation 460, a broker may receive a request for data associated with the edge server from a third party computing device, application, etc.
At operation 470, The broker may authenticate that the third party computing device is authorized to receive the data. Furthermore, the broker may fetch blocks of data associated with the request, unwrap the blocks of data, and distributes the block of data to the third party computing device.
Although the present technology has been described in detail for the purpose of illustration based on what is currently considered to be the most practical and preferred implementations, it is to be understood that such detail is solely for that purpose and that the technology is not limited to the disclosed implementations, but, on the contrary, is intended to cover modifications and equivalent arrangements that are within the spirit and scope of the appended claims. For example, it is to be understood that the present technology contemplates that, to the extent possible, one or more features of any implementation can be combined with one or more features of any other implementation.
Reference throughout this specification to “one embodiment”, “an embodiment”, “one example” or “an example” means that a particular feature, structure or characteristic described in connection with the embodiment or example is included in at least one embodiment of the present invention. Thus, appearances of the phrases “in one embodiment”, “in an embodiment”, “one example” or “an example” in various places throughout this specification are not necessarily all referring to the same embodiment or example. Furthermore, the particular features, structures or characteristics may be combined in any suitable combinations and/or sub-combinations in one or more embodiments or examples. In addition, it is appreciated that the figures provided herewith are for explanation purposes to persons ordinarily skilled in the art and that the drawings are not necessarily drawn to scale.
Embodiments in accordance with the present invention may be embodied as an apparatus, method, or computer program product. Accordingly, the present embodiments may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.), or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “module” or “system.” Furthermore, the present invention may take the form of a computer program product embodied in any tangible medium of expression having computer-usable program code embodied in the medium.
Any combination of one or more computer-usable or computer-readable content may be utilized. For example, a computer-readable medium may include one or more of a portable computer diskette, a hard disk, a random access memory (RAM) device, a read-only memory (ROM) device, an erasable programmable read-only memory (EPROM or Flash memory) device, a portable compact disc read-only memory (CDROM), an optical storage device, and a magnetic storage device. Computer program code for carrying out operations of the present invention may be written in any combination of one or more programming languages.
The flowcharts and block diagrams in the flow diagrams illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It will also be noted that each block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, may be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions. These computer program instructions may also be stored in a computer-readable medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture including instruction means which implement the function/act specified in the flowcharts and/or block diagrams.
Claims
1. A method for protecting transfer of data, the method comprising:
- initializing a processor of an edge server a first time, wherein the initialization of the processor includes loading drivers, firmware, and an operating system for the edge server;
- automatically and internally generating a private-public key pair for the metering device upon initialization the processor the first time, the private-public key pair including a private key and a public key;
- transmitting the public key from the edge server to a router a single time;
- receiving, at the edge server, analog data from a data computing device;
- creating, via the private key stored on the edge server, a digitally signed hash for the analog data;
- transmitting, from the edge server, the digitally signed hash to the router without the public key.
2. The method of claim 1, further comprising:
- checking, via the router, the digitally signed hash utilizing the public key that was received before receiving the digitally signed hash.
3. The method of claim 2, further comprising:
- storing the data associated with the digitally signed hash.
4. The method of claim 3, further comprising:
- receiving, at a broker, a request for data associated with the digitally signed hash from a third party computing device.
5. The method of claim 4, wherein the broker is configured to authenticate the third party computing device before transmitting raw data associated with the request for data.
6. The method of claim 5, wherein the broker and the router are associated with a cloud computing service provider.
7. The method of claim 1, wherein the edge server is configured to transmit the digitally signed hash over a public network.
8. The method of claim 1, wherein the data computing device is a metering device.
9. The method of claim 1, wherein the data computing device is a service provider computing device configured to provide a service.
10. The method of claim 1, wherein the public key is automatically transmitted as part of a root of trust procedure.
Type: Application
Filed: Jul 10, 2023
Publication Date: Nov 9, 2023
Applicant: VITRO TECHNOLOGY CORPORATION (Austin, TX)
Inventor: David H. Goodman (Austin, TX)
Application Number: 18/220,002
