Classifications

• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/04—Payment circuits
  • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
  • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
  • G06Q20/0655—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash e-cash managed centrally
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/60—Protecting data
  • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
  • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
  • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
  • G06Q20/3227—Aspects of commerce using mobile devices [M-devices] using secure elements embedded in M-devices
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/38—Payment protocols; Details thereof
  • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
  • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/38—Payment protocols; Details thereof
  • G06Q20/386—Payment protocols; Details thereof using messaging services or messaging apps
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/38—Payment protocols; Details thereof
  • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
  • G06Q20/401—Transaction verification
  • G06Q20/4016—Transaction verification involving fraud or risk level assessment in transaction processing
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/12—Applying verification of the received information
  • H04L63/126—Applying verification of the received information the source of the received data
• • 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/3234—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 additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
• • 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
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
  • H04W12/02—Protecting privacy or anonymity, e.g. protecting personally identifiable information [PII]
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
  • H04W12/06—Authentication
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q2220/00—Business processing using cryptography
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
  • H04L2209/12—Details relating to cryptographic hardware or logic circuitry
  • H04L2209/127—Trusted platform modules [TPM]
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
  • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
  • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates

Definitions

• a private key is applied to sign a request.
• the execution environment is responsible for the accuracy of the request and protection of the private key. Attestation to the health and origin of the execution environment establishes its reliability.
• username/password has a role to play. But most of the time users engage with the same devices for the same interactions. By leveraging the devices they own to conduct basic authentication this consistency can be rewarded with immediate access for users and increased assurance for service providers.
• Installing and running apps is meant to be very simple. However, there is a class of apps that can benefit greatly from strong assurance of their origin and opaque separation from the execution of other apps. This may be, for example, a Trusted Execution Environment or TEE. Unlike an app running on the primary OS and memory stack, an app running in a TEE can have access to cryptographic primitives that can be exercised without snooping by the OS. In ideal circumstances it also has direct access to user input and display to ensure a private interaction with the operator of the device.
• TEE Trusted Execution Environment
• TPM Trusted Platform Module
• TCG Trusted Computing Group
• TPM's having be shipping for half a dozen years and are now widely prevalent in modern PC's.
• Microsoft logo compliance beginning in 2015 will further ensure that no machine is delivered without a TPM.
• a TPM is relatively simple. It serves three basic purposes: PKI, BIOS integrity and encryption.
• the chip has no identity of its own, but can be asked to generate key pairs.
• AIK's, or Attestation Identity Keys can be marked as "non-migratable" so that the private half of the key pair will never be visible outside the hardware. This provides an opportunity to establish a machine identity that cannot be cloned.
• Some embodiments of the present invention apply these technologies into a set of services for enhancing the transaction environment that connects people and the block chain.
• Second factor authentication is well established though in limited use. It is perhaps utilized most prominently by Bitcoin service sites, where breaching a login can provide immediate and irreversible theft of funds. Most people are familiar with second factor in the form of a SMS confirmation or key fob. You enter your username and password and then you enter the code messaged to your registered phone. Second factor authentication is an important step for login security, however, it burdens the user with additional work. Even if we understand why it's important, civilization is naturally lazy. Many sites allow users to opt out of repeated confirmations and many users readily select this time saving degradation of security. A further example method, may be to first validate with the device from which the authentication request is sent.
• a recent statement declaring a clean boot sequence can give a service provider some confidence that the machine is not compromised. Attributes that provide singular assertion of a fact can also be useful without divulging much PII, for example, the machine operator has been validated as over 21, or as a French citizen or member of an affinity club. In most cases, an interaction with a device is an opportunity to collect a statement of its boot integrity. This is nothing more than a collection of hashes that can be compared against the last boot statement. A machine that booted in a predictable way is believably more reliable than one who has changed BIOS or OS. In addition to PCR quotes, participating anti-virus software can deliver a statement that the machine was cleared as of the last scan.
• verifying the integrity of the signature includes the device providing the electronic signature based on a determination of whether the execution environment of the device is in a known good condition; allowing the transaction to proceed if the device provides the electronic signature; allowing the transaction as intended by the user to proceed even if it is determined that the execution environment of the device is not in a known good condition if the remediation authority provides the signature.
• the out of band process may further include using an N or M cryptographic key function to confirm that at least one of an intent of the user meets predetermined
• Another exemplary embodiment is a computer- implemented system of verifying device integrity of a user device in a block chain communication network comprising a block chain communication network; a user device in the block chain network; an electronic transaction in the block chain network; a device verification process implemented as a part of the transaction in preparation for delivery of the electronic transaction in a block chain network, the implementation further comprising an internal validation of the integrity of the device execution environment performed from a root of trust in the device; an electronic signature, such that a verification of the integrity of the signature is applied to the block chain transaction; wherein verification of the integrity of the signature is based on a determination of whether the execution environment of the device is in a known good condition including: based on the integrity of the signature, allowing the transaction to proceed or requesting a remediation authority to verify that the electronic transaction as intended by the user is allowed to proceed even if it is determined that the execution environment of the device is not in a known good condition.
• One example preferred embodiment includes device code executed in the Trusted Execution Environment (TEE).
• TEE preferably is a hardware environment that runs small applets outside the main OS. This protects sensitive code and data from malware or snooping with purpose-built hardware governed by an ecosystem of endorsements, beginning with the device manufacturer.
• FIG. 2A is a block diagram showing an example device authentication system according to the invention, with components 200.
• web developers and app developers can make use of hardened encryption and identity keys in endpoint User Devices 205 through an application program interface (API).
• API application program interface
• further services may be provided built on these system components 200 for device management, backup, attestation, etc.
• the registration of identity keys and a set of device management services for attestation, backup and device grouping are managed.
• the Encoder 210 which prepares an instruction for a User Device 205 and at the other is the Device Rivet which is the Trusted Execution Environment (TEE) applet 208 that can act on that instruction.
• TEE Trusted Execution Environment
• a Protocol defines how these instructions and replies are constructed.
• the Device Rivet or TEE applet 208 preferably embodies the innovative binding between the physical and digital works.
• the Device Rivet or TEE applet 208 locks features of identity, transaction and attestation to the hardware of the Device 205.
• the system 200 may use a secure socket to maintain a persistent connection with all devices. This channel is used for pairing and other administrative functions.
• Library code 209 may be provided to service providers for simplifying the construction and signing of an instruction. This Library 209, for example, could be implemented in a programming language, such as an object-oriented, high-level programming language with dynamic semantics like Python.
• the Ring Manager 212 can be implemented as a service provided to end- users for managing collections (or Rings) of User Devices 205.
• Devices 205 may be grouped into a single identity and used to backup and endorse each other. Rings may be associated with other rings to create a network of devices.
• the rings are a collection of individual device public keys (as opposed to a new key). If there are not many shared devices in the environment, preferably the list of devices preferably may short because of the potential for increased computational and bandwidth resources may expended and introduce a time cost in order to encrypt a message with all of the public keys on a device list.
• a ring may be implemented as a shared private key on top of the unique private key of the Device 205. It should be noted, however, it is not typical to share a "private key", nor would it be desirable to have a long-lived shared symmetric key.
• Encryption and decryption is triggered locally and takes place within the secure execution environment so as to protect the key; creating a Bitcoin account - the device can be asked to generate a new Bitcoin account using the random number generator (RNG) built into the TEE; signing a Bitcoin transaction - the device can apply its private Bitcoin account key to sign a transaction and then return it to the service provider; securing confirmation - newer TEE environments support trusted display and input in addition to trusted execution. Trusted display enables a simple confirmation message, such as "confirm transaction amount,” to be presented to an end user; joining devices to share and backup identities - most users have several devices. Certain embodiments of the invention enable multiple devices to be bound into a ring so they can interchangeably present themselves to a service provider on behalf of the user.
• Deploying an applet into a TEE is akin to delivering a dedicated hardware device. Execution and data are cryptographically isolated from any other function of the host. While most applications of Trusted Execution technology have been concerned with enterprise security or DRM, an embodiment of the invention instead provides an applet that is focused on the needs of common web services. Crypto currencies such as Bitcoin have highlighted the need for consumer key security.
• An embodiment of the invention provides a native API that translates calls into a secure environment. While different TEE environments follow very different architectures, the API of an embodiment of the invention is designed to present a uniform interface to the application. As with all TEE applets, TEE applets according to embodiments of the invention cannot be installed and initialized without a Trusted Application Manager, or TAM. The TAM plays a role akin to a certification authority (CA). A TAM secures a relationship with a device manufacturer and also signs all applets that may be loaded into the device. In this way the TAM expresses assurance about the provenance and integrity of both the applet and the TEE.
• CA certification authority
• Embodiments of the invention provide device integrity attestation by automating the assurance of device integrity against a known state as a signatory on a block chain transaction.
• the system implemented by an embodiment of the invention is comprised of the several components shown in FIG. 2C.
• a Device Adapter 220 is a software service running on an endpoint device that provides an interface to a Service Provider 204 application and integrates with the Device TEE 208.
• the Trusted Execution Environment (TEE - sometimes TrEE) is a mobile phone hardware security chip separate execution environment that runs alongside the Rich OS and provides security services to that rich environment.
• the TEE offers an execution space that provides a higher level of security than a Rich OS; though not as secure as a Secure Element (SE) (aka SIM), the security offered by the TEE is sufficient for some / many applications. In this way, the TEE delivers a balance allowing for greater security than a Rich OS environment with considerably lower cost than an SE.
• SE Secure Element
• the Device TEE 208 is a software program that executes in a hardware secured TEE.
• the Device TEE 208 is specially designed to execute cryptographic functions without compromise from malware or even the device operator.
• the Device Registrar 221 is a service that registers a device into the block chain 222.
• a block chain 222 is used both to store device registration and attributes and to execute transactions. There may be different block chains.
• Another supporting component is a Service Provider 204 which is the application seeking to conduct a transaction with a device. OEM (Original
• Equipment Manufacturer 223 is the entity that built the device and/or a Trusted Application Manager (TAM) authorized to cryptographically vouch for the provenance of the device.
• TEE Trusted Application Manager
• the Device Adapter 221 shown in FIG. 2C software runs for the first time it will ask the Device TEE 208 to generate a public/private key pair.
• the public key is signed by an endorsement key established during device manufacturing. This signed public key is sent to the Device Registrar 221 and validated with the OEM 223. Registration may involve confirmation from the device operator. Registration may involve endorsement at the point of sale in the presence of a clerk.
• the Registrar may ask the device for a Device Measurement Record which includes one or more of the following: a composite value of the Platform Configuration Registers (PCR's) generated by the boot process, BIOS Version, OS Version, GPS Location. This data is signed by the device private key. It is further signed by the Registrar. The resulting data set becomes the gold reference or Reference Value for future integrity checks.
• PCR's Platform Configuration Registers
• Confirmation from the device operator may be required in collecting the gold reference or Reference Value.
• This data set is posted into a public cryptographic ledger.
• the public record established cryptographic proof of the time of registration along with the endorsement of the registrar.
• the registration may further include attribute data, such as location or company name or device make/model.
• the registration may reference a signed document that sets out the policy terms of the registrar at the time of registration.
• the Device Registrar 221, or another trusted integrity server creates a block chain account key (a public/private key pair) that can be referenced as a signatory in a multi-signature transaction on the block chain. A signatory the value represented in the block chain transaction cannot be spent or transferred unless co-signed by the Registrar.
• the integrity server expects a recent measurement from the device. This measurement may be requested directly of the Device Adaptor or fetched by the server through a persistent sockets connection with the device. The current measurement is compared against the gold measurement or Reference Value in the block chain. If the measurements match the transaction is signed. If the measurements match but the recent measurement is older than a specified time window, the request is rejected. If the measurements do not match, the request is rejected. If there is a rejection, the transaction may have been prepared with another manual signatory that can be asked to override the rejection. If the measurements do not match, the device may be put through a registration renewal where a new measurement is gathered. Every time a measurement matches, the device registration record can be updated with a success count. The integrity server may be given policy rules that will accept a measurement which doesn't match if the problem is not deemed severe in light of other matching measurements or attributes.
• Authentication Web Site 206 may be a JSON API written in Python, which uses the Third Party Agent/Process private key to enroll the identity keys of Devices 205 and Service Providers 204.
• the public key of the User Device 205 or Service Provider 204 is recorded by the TEE applet 208. Enrollment enables the TEE applet 208 to pair a Device 205 with a Service Provider 204. The result of pairing is that a User Device 205 has a service public key, endorsed by a Third Party Agent/Process and can therefore respond to Service Provider 204 instructions.
• the Protocol specifies the structure of an instruction and the signing/encryption that must be applied for the Device 205 to accept the instruction.
• the instruction itself may, for instance, be prepared as a C structure that contains the instruction code, version data and payload.
• the entire structure preferably is signed by the service provider key and delivered to the device TEE applet 208 by calling a device local command.
• every User Device 205 should present unique identity credentials.
• Devices may join a ring so as to act as a singular entity.
• a Device 205 can support group ID's that are locally stored as a list, but publicly translate into cross-platform authentication.
• the TEE Adapter 216 may be configured as the interface between the Device Rivet/TEE applet 208 bolted into the TEE and the outside world of partner apps and online services. In implementation, it can manifest in one or more diverse forms, which would be at least partially dictated by the basic capabilities across devices, hardware support and OS architecture.
• the Authentication System Adaptor 214 is composed of outward and inward looking interfaces as shown in FIG. 2D.
• the inward looking interface, the TEE Adapter 216 handles proprietary communications with the Device Rivet 208.
• the Host Adaptor 217 is provided to expose services to third-party applications.
• the Host Adaptor 217 presents the interface of the Authentication System Adaptor 214 through different local contexts, such as browsers or system services. Multiple realizations for diverse contexts are anticipated though initially this may be an Android service and a windows com process.
• the Socket Adaptor 215 connects the client environment Authentication Web Site 206.
• the TEE Adaptor 216 component is the proprietary glue that pipes commands into the Device Rivet 208.
• the Authentication System Adaptor 214 may manifest as an Android NDK service app and may be configured to launch at boot.
• Authentication System Adaptor 214 prepares message buffers that are piped to the Device Rivet 208 and then synchronously awaits notification of a response event.
• the Host Adaptor 217 is primarily there to isolate the TEE Adapter 216 from the host environment.
• the Host Adaptor 217 operates in a potentially hostile environment. There will therefore typically be limited assurance that the client has not been compromised.
• the Host Adaptor's role is therefore primarily to facilitate easy access to the Device Rivet 208. Instructions from a Service Provider 204 intended for the Device Rivet 208 will be signed by the Service Provider 204 and then passed through to the TEE Adapter 216 and Device Rivet 208.
• the Authentication Web Site 206 is the first service provider registered to a Device 205.
• the Authentication Web Site 206 has the special capability of being able to pair additional service providers with that Device 205. Communications with the Authentication Web Site 206 may be handled through the web API and should be authenticated. In one example, this is implemented with an API key. In a preferred example embodiment, this is implemented using an SSL key swap. In some embodiments, all requests will be signed.
• the relationship with devices may be dependent on being able to sign instructions with the private key.
• a private key is highly sensitive and is protected.
• the private key is encased in an HSM.
• multiple keys are used, such that if one is compromised the whole system is not lost. This should, for example, should make it more difficult for an attacker to know which devices are connected with a compromised key.
• the system 200 is preferably in near constant contact with all Devices 205 through the Socket Adapter 215 shown in FIG. 2C, which can facilitate frequent rotation of the keys.
• the Authentication Web Site 206 may comprise several sub-components.
• a Device ID is the unique identifier, in a UUID, assigned to a device by the Authentication Web Site 206 or other Registration Agent.
• An ephemeral pointer, Device Pointer may be provided to a device 150 that can be requested by any local application.
• the Device Pointer can identify a current socket session to the Authentication Web Site 206 and therefore can be used to establish a device communication channel and to look up the permanent identifier, the Device ID.
• the root of a device registration includes a unique, anonymous identifier, a registration date, a public key paired to a private key held in the device hardware and an endorsement signature from the Registration Agent. This information is recorded in the Device Registration Record.
• the TEE applet 208 embodies the binding between the physical and digital works.
• the Device Rivet 209 locks features of identity, transaction and attestation to hardware.
• the Encoder 210 prepares a command to be executed by a specific device which is signed and/or encrypted by the Service Provider 204.
• the Service Provider public keys are preloaded into the device during a pairing process conducted by Authentication Web Site 206. This allows the Device Rivet 209 to validate the origin of the request, and if needed decrypt the contents of the instruction.
• the sequence of packaging and delivering an instruction is shown in FIG. 3 A.
• the Service Provider 204 generates an Instruction Record with the help of the Encoder 210 libraries.
• the instruction includes the type, the target device and payload.
• the instruction may be encoded with the device key and must be signed by the service provider key.
• the device key is fetched from the Authentication Web Site 206, or directly from the block chain, by looking up the Device Registration Record.
• Device enrollment or creation of a birth certificate for a device on the block chain is essential to example embodiments of the invention.
• the enrollment process, shown in FIG. 3B, must be hassle free or even transparent to the user.
• a fully reputable Device ID would include personalization of the
• the 220 software runs for the first time it will ask the Device TEE 208 to generate a public/private key pair.
• the public key is signed by an endorsement key established during device manufacturing. This signed public key is sent to the Device Registrar
• the registration may further include other attribute data, such as location or company name or device make/model.
• the registration may reference a signed document that sets out the policy terms of the registrar at the time of registration.
• the Device Registrar 221, or another trusted integrity server creates a block chain account key (a public/private key pair) that can be referenced as a signatory in a multisig transaction on the block chain. A signatory value represented in the block chain transaction cannot be spent/transferred unless co-signed by the Registrar 221.
• the integrity server expects a recent measurement from the device. This measurement may be requested directly of the device adapter or fetched by the server through a persistent sockets connection with the device.
• the current measurement is compared against the gold measurement in the block chain. If the measurements match the transaction is signed, if the measurements match but the recent measurement is older than a specified time window, the request is rejected. If the measurements do not match the request is rejected. If there is a rejection, the transaction may have been prepared with another manual signatory that can be asked to override the rejection. If the measurements do not match the device may be put through a registration renewal where a new measurement is gathered. Every time a measurement matches, the device registration record can be updated with a success count.
• the integrity server may be given policy rules that will accept a measurement which does not match if the problem is not deemed severe in light of other matching measurements or attributes. This system may be implemented with a collection of trusted devices rather than an integrity server to do the work of matching
• This system may match integrity measurements directly during transaction processing using features built into a smart block chain system such as that being developed by Ethereum.
• the method may include enrolling the device with a third party is at the request of the first service provider seeking to pair with the device.
• enrolling the device may be provided as a service.
• Endorsing of the device measurement record by the device may include signing of the record by the device private key.
• Endorsing of the device measurement record by the third party may be provided as a service.
• the registration may further include signing of a document that sets out the policy terms of the registration provider at the time of registration.
• the cryptographic ledger may be Namecoin.
• the endorsed device measurement record may establish a Reference Value for transactions between a service provider and the device. Additionally, confirmation by the device operator is required to obtain the device measurement record of the device attributes from the device.
• the device attributes may further include location, company name and/or device make/model. Further, the transaction between a service provider and the device may require the device to generate and provide a device measurement record that is compared to the established Reference Value for the device.
• the transaction is allowed if the comparison results in a match or the transaction is rejected if the comparison results in no match or the transaction is rejected if the comparison results in a match and the record provided by the device is older than a specified time window or the device is required to re-create its birth certificate if the comparison results in no match.
• registering the device into the block chain may further include creating a device registration record that is updated with a success count if the comparison results in a match.
• the comparison may be implemented by a collection of trusted devices.
• the entity performing the comparison may be independent of the entity performing the registration.
• Another embodiment may be a system comprising a block chain communication network; a user device in the block chain network; a trusted third party; and a system for creating a birth certificate for the user device, said system configured to establish a device identity for the user device by generating a public/private key pair that is locked to the user device; sign the public key of the device using an endorsement key established during manufacturing or creation of the device, manufacturing or creation of the execution environment of the device and/or manufacturing or creation of an application on the device; and enroll the device with the trusted third party by: requesting and obtaining the generated public key from the device; requesting and obtaining a device measurement record of the device containing attributes related to the device Platform Configuration Registers (PCR), BIOS, OS and/or GPS; endorsing of the device measurement record by the third party and the device; and registering the device into the block chain by posting the endorsed device measurement record into a public cryptographic ledger; and creating a block chain account key pair that can be referenced as a signatory in a multi signature transaction on
• a bitcoin Wallet functions similarly to a bank account and can be used to receive and store bitcoins as well as transfer them to others in the form of electronic transaction in the Bitcoin block chain.
• a bitcoin address is a unique identifier that allows a user to receive Bitcoins. Bitcoins are transferred by sending them to a bitcoin address. The transactions in the Bitcoin block chain are usually free.
• a Wallet stores the private keys so that the user can access bitcoin addresses.
• a service may be provided whereby a bitcoin transaction accumulates to a new license right. This would be done by integrating a smart contract with attribute information in the transaction record that would identify the chain of transactions that accumulate to a right. Ultimately this right would be bound to the original Wallet address. Every time a specific item is purchased it would incorporate the last transaction as part of the attribute data of the current transaction assuring that the accumulation of transactions could be quickly and efficiently verified by reading the information on the block chain. The act of performing many small transactions on the block chain would enable an account to easily accumulate to an ownership right or a replay right. Once a specific level is reached, the accumulation would stop and a persistent right would be written to the block chain.
• Some embodiments may include systems and methods for attesting to device health prior to engaging in electronic transactions.
• a system for may be provided for accumulating a value attached to transactions in a block chain communication network associated with a bitcoin account, the system comprising a block chain communication network; an electronic transaction in the block chain network; a bitcoin account; a transaction record associated with the bitcoin account; a transaction interrogation process implemented as a part of executing the electronic transaction in a block chain network.
• the implementation may further comprise a checking of the transaction record for the existence of a previous transaction associated with the account; and based on the existence of a previous transaction: obtain an accumulated value attached to the previous transaction; increment the obtained accumulated value; attach the incremented accumulated value to the transaction in the transaction record; and apply the incremented accumulated value to the transaction.
• the implementation of the transaction interrogation process may further comprise setting a plurality of charges incurred for executing the electronic transaction to zero and indicating the achievement of a Right associated with the account, based on the incremented accumulated value reaching or exceeding a predetermined maximum accumulated transaction value.
• the implementation of the transaction interrogation process may further comprise creating a new transaction record associated with the account; and storing an indication of the achieved Right in the newly created transaction record.
• the electronic transaction may be associated with a specific Item, the transactions in the transaction record associated with the account form a chain with cryptographic assurance and the implementation of the transaction interrogation process may further comprise: allowing a user to query the last transaction recorded in the transaction record associated with the account; and calculating a level of expenditure for the specific Item based on cryptographic assurance of the formed chain.
• Applying the accumulated value to the transaction may include associating the achieved Right with a cryptographic key; storing the key in a tamper resistant storage; obtaining a set of transactions contributing to the accumulated value associated with the achieved Right; and verifying the set of transactions prior to applying the accumulated value to the transaction.
• the set of transactions must be completed within a specific period of time in order to contribute to the achievement of the Right.
• the achieved Right expires after a specific period of time and/or expires based on the lack of use of the Right.
• the achieved Right is used as part of a multiple signature transaction to enable the purchase of additional transactions requiring an indication of the achieved Right.
• the transaction is associated with a single Item and involves two achieved Rights and the accumulated values associated with the Rights are cryptograhically merged to result in a single accumulated value.
• the current state of computing is based on an authentication model in which devices connect to a cloud service like Twitter and then assume that the follow-on data is correct. Encrypted transport is commonly used and the assurance model is based on assuring the whole computer that sends the data. Technologies like anti-virus and integrity validation are provided for the host system. An assumption is made that the complex system is okay and to trust the critical data delivered.
• Authentication may be augmented with assured computer instructions that are formed within the local device from both remote sources to assure these instructions are correct and to then deliver these instruction to remote services for processing.
• the system may collect data from user input, device input, remote system input and then provide a secure mechanism for the user to confirm this is the intended transaction to be performed.
• the cloud service receives this assured instruction and verifies that the elements of the transaction are correct.
• the verification process may also impose local or remote policies that are verified prior to the transaction being accepted for processing. The resulting data can then be logged.
• authentication is used to connect to critical services. Even with strong authentication there is no assurance that the information sent to the cloud is the information the user intends. Malware can find many ways to alter the data and result in the theft or compromise of sensitive data.
• the purpose of this invention is to collect a number of sources of both local and remote data to assure that the information provided is the data that is intended. Certain data could also be locally masked to assure a process has been completed but the detailed private information remains masked. Services can then verify the transactions are intended and incorporate a number of additional process steps internally and externally that are controlled by the user. This can assure logging and additional verification to assure the transaction is correct. This can be used in financial systems but also to control the internet of things from door locks to medical devices.
• local data could be tokenized to protect privacy.
• the users phone number could be used to say they are a specific provider's customer and in good standing but all that is passed on is the good standing status and not the users name or phone number. This is done by contacting the provider locally and having the confirmation data include a provider transaction identity that can be remotely verified.
• Systems may be configured with a logic script that is cryptographically assured to provide the policy required for a specific transaction.
• the script validation may be included as part of the transaction verification data.
• Systems may include local or remote approvals prior to the transaction being released (i.e. multi signal on the client side).
• the systems may receive real time data that is locally assured and then modified so the instruction is a delta to a real time state, for example, to increase speed of a pump.
• the verifying device assures that the transaction came from a known source that meets the minimum number of parameters.
• the receiving device additionally verifies local or remote information.
• Rivetz enables web developers and app developers to make use of hardened encryption and identity keys in endpoint devices through a simple API. To support this system we manage the registration of identity keys and a set of device management services for attestation, backup and device grouping.
• the Ring Manager is a service provided to end-users for managing collections (or Rings) of devices. Devices may be grouped into a single identity and used to backup and endorse each other. Rings may be associated with other rings to create a network of devices.
• RivetzNet is the first service provider registered to a device and has the special capability of being able to pair additional service providers with that device. All communications with the Web API need to be authenticated. We could use an API key or better yet, an SSL key swap. We could ask that all requests be signed, but we have to be cognizant of keeping our system simple to use.
• RivetzCoinAccount Given unique identifier and a public key, purchase a record of this binding in the block chain. The purchase is made with RivetzCoinAccount thus endorsing the registration. Ideally, the Rivetz signature would only be applied if the device can supply an endorsement key from the OEM.
• the RivetzEncoder is software written to be hosted by our partners.
• the RivetzEncoder is distributed as public open source. b. Entity Responsibility

Landscapes

• Engineering & Computer Science (AREA)
• Business, Economics & Management (AREA)
• Computer Security & Cryptography (AREA)
• Accounting & Taxation (AREA)
• Theoretical Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• General Physics & Mathematics (AREA)
• Physics & Mathematics (AREA)
• Signal Processing (AREA)
• Strategic Management (AREA)
• General Business, Economics & Management (AREA)
• Finance (AREA)
• General Engineering & Computer Science (AREA)
• Computer Hardware Design (AREA)
• Computing Systems (AREA)
• Health & Medical Sciences (AREA)
• Bioethics (AREA)
• General Health & Medical Sciences (AREA)
• Software Systems (AREA)
• Management, Administration, Business Operations System, And Electronic Commerce (AREA)
• Storage Device Security (AREA)
• Electrotherapy Devices (AREA)

Priority Applications (8)

Applications Claiming Priority (4)

Publications (1)

Family

ID=56923881

Family Applications (1)

Country Status (10)

Cited By (20)

Families Citing this family (340)

Citations (6)

Family Cites Families (33)

• 2016
  • 2016-03-18 RU RU2017135040A patent/RU2673842C1/ru not_active IP Right Cessation
  • 2016-03-18 CA CA2980002A patent/CA2980002A1/en not_active Abandoned
  • 2016-03-18 KR KR1020177030054A patent/KR20170129866A/ko not_active Withdrawn
  • 2016-03-18 AU AU2016235539A patent/AU2016235539B2/en not_active Ceased
  • 2016-03-18 WO PCT/US2016/023142 patent/WO2016154001A1/en not_active Ceased
  • 2016-03-18 CN CN201680027846.1A patent/CN107533501A/zh active Pending
  • 2016-03-18 EP EP16769411.6A patent/EP3271824A4/en not_active Withdrawn
  • 2016-03-18 HK HK18109340.8A patent/HK1249945A1/zh unknown
  • 2016-03-18 US US15/074,784 patent/US20160275461A1/en not_active Abandoned
  • 2016-03-18 JP JP2018500269A patent/JP2018516026A/ja active Pending

Patent Citations (6)

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events