CA2986731A1 - A blockchain based smart home security solution - Google Patents
A blockchain based smart home security solution Download PDFInfo
- Publication number
- CA2986731A1 CA2986731A1 CA2986731A CA2986731A CA2986731A1 CA 2986731 A1 CA2986731 A1 CA 2986731A1 CA 2986731 A CA2986731 A CA 2986731A CA 2986731 A CA2986731 A CA 2986731A CA 2986731 A1 CA2986731 A1 CA 2986731A1
- Authority
- CA
- Canada
- Prior art keywords
- nodes
- node
- record
- information
- interaction
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
- H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
BACKGROUND
The advantages of a decentralized database have been stressed upon by many sources, mostly relating to cryptocurrency and business management. While these large-scale applications are useful in their own way, smaller scale applications such as private or commercial security can also have merit. A security system with such a decentralized database that can verify accessors while being difficult to tamper with would be effective. Blockchains inherently contain a record of past activity while being difficult to fake. A system that uses blockchain technology and a user login/password system would solve these problems.
FIELD OF INVENTION
The system described relates to blockchain technology and the study of decentralized databases and their applications. The system also falls under electronic security systems.
DESCRIPTION
The system is composed of nodes.
One such example of the function of these nodes (shown in FIG. A) would be keys (001, 003), keyholes (002), and server(s) (004), which may or may not be the only example of nodes. (001) and
The advantages of a decentralized database have been stressed upon by many sources, mostly relating to cryptocurrency and business management. While these large-scale applications are useful in their own way, smaller scale applications such as private or commercial security can also have merit. A security system with such a decentralized database that can verify accessors while being difficult to tamper with would be effective. Blockchains inherently contain a record of past activity while being difficult to fake. A system that uses blockchain technology and a user login/password system would solve these problems.
FIELD OF INVENTION
The system described relates to blockchain technology and the study of decentralized databases and their applications. The system also falls under electronic security systems.
DESCRIPTION
The system is composed of nodes.
One such example of the function of these nodes (shown in FIG. A) would be keys (001, 003), keyholes (002), and server(s) (004), which may or may not be the only example of nodes. (001) and
(002) show an example of a hardware element used as a key with a hardware element used as a keyhole. (003) shows the same relationship as (001) but with software components, the example given being a smart device with an installed software application as a software key. (004) shows an example of a possible network of servers that the keys and keyholes interact with, which in this example is a peer-to-peer network (P2P).
An interaction between a key and a keyhole allowing user access is referred to in this document as a transaction. This may or may not be the only example of possible transactions for this system.
Keys and keyholes may or may not store the following information which may or not be the only information stored within: an identifier that the system can recognize belongs to a valid node, a record of the identifiers of other nodes, and a record of previous valid transactions. An identifier may or may not be exclusive to a particular key or keyhole as long as it is valid (fulfills requirements that allow it to serve as an identifier which may or may not include characteristics such as number of transactions, type of data, format of data, etc. which may or may not be customizable by the user). The record of previous valid transactions may or may not include all the valid transactions that have occurred since the initialization of the system, and may or may not be truncated in some way.
The number of transactions stored on the keys and keyholes may or may not be the same, whether among themselves or each other. The record of transactions may or may not be updated on some basis, regular or irregular, and may or may not be updated based on the record of another valid node or other source.
The information that is sent across the networks between nodes may or may not be encrypted with some known algorithm. The information contained within nodes may or may not be encrypted with some known algorithm.
The key(s), keyhole(s), and server(s) may or may not be connected in some way to other server(s) in a larger network beyond just the system owned by the user The server node may or may not be computationally stronger than non-server nodes, and the role of a server node may or may not be assigned to an another node which may or may not occur at any time and may or may not be computationally weaker. The reasons for this may or may not include user settings, server availability, system condition, etc.
The key nodes may or may not be computationally weaker than other nodes, and may or may not have any computing ability of their own. The keys may or may not rely on the other nodes to update or otherwise change the information stored within the key nodes.
All nodes may or may not have to be available for communication to allow access. As long as a sufficient number of nodes can verify the transaction, the transaction may be considered valid.
This number of sufficiency may or may not be predetermined by the user or some other source.
The nodes may or may not be unevenly given importance for the verification process so that the verification conclusion of one node can overrule the verification conclusion of another. This system of uneven importance may or may not be altered or assigned at any time by a source which may or may not be arbitrary, and may require the verification from certain important nodes for the transaction to be considered valid.
The addition or the removal of a node requires the entire system to recognize the change as valid and may or may not involve the assignment or removal of the node's identifier that the system can recognize belongs to a valid node, the node's record of the identifiers of other nodes, the node's record of previous valid transactions, and other data that may or may not be stored on the node.
This assignment or removal may or may not involve any combination and any number of these listed previous.
The user may or may not override the system using some function which may or may not be a username/password system or just a password, an access key which may or may not be hardware or software, or some other sort of identification verification entirely. This override will bypass the initial verification required in the following two examples given but the record of entry will still be stored on the node system in the same way.
The user may or may not choose to have failed transactions stored in the system in some way as well. This choice may or may not be made by another entity. The details of the transaction attempt may or may not also be stored, whether this implies time of attempt, frequency of attempts, identity of attempt, location of attempt etc. These failed attempts may or may not be stored in the same way as standard successful attempts, but may or may not be stored in the same location, across all nodes, with the same encryption, on the same chain, or in some other matter or design.
One example of the system's function may comprise of the following steps, as shown in FIG. B:
1) To gain access, the user will complete an action which will cause a key and keyhole to initiate a transaction (101), which may or may not contain information about the particular key, the particular keyhole, and other relevant information. This information may or may not include data such as the time, the date, the location, the frequency, the device used, the model of key/keyhole, etc. There may or may not be other information included.
2)The user may override the system (102) as described previous, in which case the system proceeds straight to updating each node with the details of the transaction (109) and granting the user access (110).
An interaction between a key and a keyhole allowing user access is referred to in this document as a transaction. This may or may not be the only example of possible transactions for this system.
Keys and keyholes may or may not store the following information which may or not be the only information stored within: an identifier that the system can recognize belongs to a valid node, a record of the identifiers of other nodes, and a record of previous valid transactions. An identifier may or may not be exclusive to a particular key or keyhole as long as it is valid (fulfills requirements that allow it to serve as an identifier which may or may not include characteristics such as number of transactions, type of data, format of data, etc. which may or may not be customizable by the user). The record of previous valid transactions may or may not include all the valid transactions that have occurred since the initialization of the system, and may or may not be truncated in some way.
The number of transactions stored on the keys and keyholes may or may not be the same, whether among themselves or each other. The record of transactions may or may not be updated on some basis, regular or irregular, and may or may not be updated based on the record of another valid node or other source.
The information that is sent across the networks between nodes may or may not be encrypted with some known algorithm. The information contained within nodes may or may not be encrypted with some known algorithm.
The key(s), keyhole(s), and server(s) may or may not be connected in some way to other server(s) in a larger network beyond just the system owned by the user The server node may or may not be computationally stronger than non-server nodes, and the role of a server node may or may not be assigned to an another node which may or may not occur at any time and may or may not be computationally weaker. The reasons for this may or may not include user settings, server availability, system condition, etc.
The key nodes may or may not be computationally weaker than other nodes, and may or may not have any computing ability of their own. The keys may or may not rely on the other nodes to update or otherwise change the information stored within the key nodes.
All nodes may or may not have to be available for communication to allow access. As long as a sufficient number of nodes can verify the transaction, the transaction may be considered valid.
This number of sufficiency may or may not be predetermined by the user or some other source.
The nodes may or may not be unevenly given importance for the verification process so that the verification conclusion of one node can overrule the verification conclusion of another. This system of uneven importance may or may not be altered or assigned at any time by a source which may or may not be arbitrary, and may require the verification from certain important nodes for the transaction to be considered valid.
The addition or the removal of a node requires the entire system to recognize the change as valid and may or may not involve the assignment or removal of the node's identifier that the system can recognize belongs to a valid node, the node's record of the identifiers of other nodes, the node's record of previous valid transactions, and other data that may or may not be stored on the node.
This assignment or removal may or may not involve any combination and any number of these listed previous.
The user may or may not override the system using some function which may or may not be a username/password system or just a password, an access key which may or may not be hardware or software, or some other sort of identification verification entirely. This override will bypass the initial verification required in the following two examples given but the record of entry will still be stored on the node system in the same way.
The user may or may not choose to have failed transactions stored in the system in some way as well. This choice may or may not be made by another entity. The details of the transaction attempt may or may not also be stored, whether this implies time of attempt, frequency of attempts, identity of attempt, location of attempt etc. These failed attempts may or may not be stored in the same way as standard successful attempts, but may or may not be stored in the same location, across all nodes, with the same encryption, on the same chain, or in some other matter or design.
One example of the system's function may comprise of the following steps, as shown in FIG. B:
1) To gain access, the user will complete an action which will cause a key and keyhole to initiate a transaction (101), which may or may not contain information about the particular key, the particular keyhole, and other relevant information. This information may or may not include data such as the time, the date, the location, the frequency, the device used, the model of key/keyhole, etc. There may or may not be other information included.
2)The user may override the system (102) as described previous, in which case the system proceeds straight to updating each node with the details of the transaction (109) and granting the user access (110).
3)The key and keyhole will accept the information and may or may not check it for errors (103) which may or may not include valid signatures, valid data, etc. If none are found (104), the key and keyhole will attach their identifiers in some way and broadcast the details of the transaction across the system to any available nodes which will do their own verification independently (105) and attach identifiers and broadcast the transaction (106) if required. If an error is found at any point by any node the transaction is ignored (1X, 1Y).
4)Through this process eventually a copy of the information will reach a server or servers which may or may not be the only server or servers in the network, which will have the identifiers of each other valid node included (107). The server may or may not be assigned randomly at any time depending on several factors which may or may not include user discretion, server availability, system condition, etc.
5)The server may or may not verify the data (108) by checking the identifiers and previous transactions in the same way as the other nodes. If the copy it had received has the signatures of each other node and the server can also verify the data the information is accepted as valid, otherwise ignored (14. The server may or may not also verify this information with other servers in the system.
6)The server may or may not then append the information to its record of past transactions and send out information to each other node (109) which may or may not be the same information or have the same characteristics of the information that the server had received, with the server's identifier attached.
7)When each other node receives this information, they will check the information for errors and if none are found, will send out this information and permanently attach the transaction to their record of previous transactions.
8)When the initial nodes receive the confirmation information, the user is allowed access (110).
Another example of the system's function which may comprise of the steps as shown in FIG. C:
1)To gain access, the user will complete an action which will cause a key and keyhole to initiate a transaction (201), which may or may not contain information about the particular key, the particular keyhole, and other relevant information, this information may or may not include data such as the time, the date, the location, the frequency, the device used, the model of key/keyhole, etc. There may or may not be other information included.
2)The user may override the system (202) as described previous, in which case the system proceeds straight to updating each node with the details of the transaction (209) and granting the user access (210).
3)The key and keyhole will compare their stored records of past transactions (203). If one record is completely found within the other (204), the comparison is considered successful. The keyhole may or may not also verify that the record of the key has at least all the transactions that have occurred between the starting point of the keyhole's record and the key's last transaction on the keyhole's record. A failed comparison will cause the node to ignore the transaction (2X).
4)The keyhole will send out the key's record information across the system to any available nodes (205), which may or may not only include keyholes in this instance. Each receiving node will accept the information and may or may not check it for errors and do its own comparison between the key's record and the receiving node's own record of transactions (206). A
successful comparison will cause the keyhole to send out this information in much the Same way to other nodes (207), a failed comparison will cause the node to ignore the transaction (2Y).
5)Eventually all available nodes will have completed a comparison of the key's record of transactions. If the comparison is successful across a sufficient number of nodes the transaction is considered valid (208). This number of sufficiency is determined as described above.
6)All available nodes including the initial key and keyhole nodes will add this transaction to their record of transactions (209).
7)The user is allowed access (210).
Another example of the system's function which may comprise of the steps as shown in FIG. C:
1)To gain access, the user will complete an action which will cause a key and keyhole to initiate a transaction (201), which may or may not contain information about the particular key, the particular keyhole, and other relevant information, this information may or may not include data such as the time, the date, the location, the frequency, the device used, the model of key/keyhole, etc. There may or may not be other information included.
2)The user may override the system (202) as described previous, in which case the system proceeds straight to updating each node with the details of the transaction (209) and granting the user access (210).
3)The key and keyhole will compare their stored records of past transactions (203). If one record is completely found within the other (204), the comparison is considered successful. The keyhole may or may not also verify that the record of the key has at least all the transactions that have occurred between the starting point of the keyhole's record and the key's last transaction on the keyhole's record. A failed comparison will cause the node to ignore the transaction (2X).
4)The keyhole will send out the key's record information across the system to any available nodes (205), which may or may not only include keyholes in this instance. Each receiving node will accept the information and may or may not check it for errors and do its own comparison between the key's record and the receiving node's own record of transactions (206). A
successful comparison will cause the keyhole to send out this information in much the Same way to other nodes (207), a failed comparison will cause the node to ignore the transaction (2Y).
5)Eventually all available nodes will have completed a comparison of the key's record of transactions. If the comparison is successful across a sufficient number of nodes the transaction is considered valid (208). This number of sufficiency is determined as described above.
6)All available nodes including the initial key and keyhole nodes will add this transaction to their record of transactions (209).
7)The user is allowed access (210).
Claims (9)
1. a system of nodes that allows access to users only if they complete an interaction that is verified by a all nodes or a limited set of predefined nodes
2. the system defined in claim 1 where the contents of a decentralized database are stored across all nodes to allow access, with only a number of members that can add to the database
3. a system of verification defined in claim lin which an interaction is considered valid upon comparison of two selected nodes with one record found within the other
4. a system of communication as described in claim 1 in which each node in any order can independently verify the interaction(s) from the other nodes
5. a system of verification in claim 4 which uses each node's database to verify an interaction
6. a system of verification in claim 4 which uses each node's identifier to verify an interaction
7. a system as described in the previous claims limited to a smart home application
8. a system as described in the previous claims to use this verification process as a record for physical or virtual logins
9. a system as described in the previous claims connected in some way to other similar systems to share information or increase blockchain security
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA2986731A CA2986731A1 (en) | 2017-11-27 | 2017-11-27 | A blockchain based smart home security solution |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA2986731A CA2986731A1 (en) | 2017-11-27 | 2017-11-27 | A blockchain based smart home security solution |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2986731A1 true CA2986731A1 (en) | 2019-05-27 |
Family
ID=66657510
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA2986731A Abandoned CA2986731A1 (en) | 2017-11-27 | 2017-11-27 | A blockchain based smart home security solution |
Country Status (1)
| Country | Link |
|---|---|
| CA (1) | CA2986731A1 (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111415161A (en) * | 2020-04-27 | 2020-07-14 | 财付通支付科技有限公司 | Block chain-based data verification method and device and computer-readable storage medium |
| CN113739017A (en) * | 2021-09-06 | 2021-12-03 | 玖陆零信安创(盐城)科技有限公司 | Remote control device for Internet of things smart home |
-
2017
- 2017-11-27 CA CA2986731A patent/CA2986731A1/en not_active Abandoned
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111415161A (en) * | 2020-04-27 | 2020-07-14 | 财付通支付科技有限公司 | Block chain-based data verification method and device and computer-readable storage medium |
| CN111415161B (en) * | 2020-04-27 | 2024-03-19 | 财付通支付科技有限公司 | Block chain-based data verification method and device and computer readable storage medium |
| CN113739017A (en) * | 2021-09-06 | 2021-12-03 | 玖陆零信安创(盐城)科技有限公司 | Remote control device for Internet of things smart home |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10708070B2 (en) | System and method for utilizing connected devices to enable secure and anonymous electronic interaction in a decentralized manner | |
| CN110675144B (en) | Enhancing non-repudiation of blockchain transactions | |
| US11177961B2 (en) | Method and system for securely sharing validation information using blockchain technology | |
| CN110785981B (en) | Securing access to confidential data using blockchain ledgers | |
| US20210133359A1 (en) | Permission management method, permission verification method, and related apparatus | |
| RU2747947C2 (en) | Systems and methods of personal identification and verification | |
| US9876775B2 (en) | Generalized entity network translation (GENT) | |
| US10587413B1 (en) | Decentralized identities for cross-enterprise authentication and/or authorization | |
| CN110945549A (en) | Method and system for universal storage and access to user-owned credentials for cross-institution digital authentication | |
| CN111756753A (en) | Authority verification method and system | |
| WO2015179020A2 (en) | Generalized entity network translation (gent) | |
| TW201810990A (en) | Blockchain-implemented method and system | |
| EP3777022B1 (en) | Distributed access control | |
| CN111327564B (en) | Access method and device for alliance chain | |
| US20190141048A1 (en) | Blockchain identification system | |
| CN110225017B (en) | Identity authentication method, equipment and storage medium based on alliance block chain | |
| CN114547636A (en) | Distributed account book system | |
| WO2021101632A1 (en) | Know your customer (kyc) and anti-money laundering (aml) verification in a multi-decentralized private blockchains network | |
| US20220116214A1 (en) | Multisignature key custody, key customization, and privacy service | |
| CN112446039A (en) | Block chain transaction processing method, device, equipment and storage medium | |
| EP4032070A1 (en) | Method, locking system for controlling access to a resource and a locking device | |
| Sari et al. | FileTribe: blockchain-based secure file sharing on IPFS | |
| CN111327426A (en) | Data sharing method and related device, equipment and system | |
| Sundari et al. | Secure multi-party computation in differential private data with Data Integrity Protection | |
| CN109981637B (en) | Multi-source cross composite authentication method for Internet of things based on block chain |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FZDE | Discontinued |
Effective date: 20191127 |