DE102017122227A1 - System, especially authenticity system - Google Patents

System, especially authenticity system

Info

Publication number
DE102017122227A1
DE102017122227A1 DE102017122227.8A DE102017122227A DE102017122227A1 DE 102017122227 A1 DE102017122227 A1 DE 102017122227A1 DE 102017122227 A DE102017122227 A DE 102017122227A DE 102017122227 A1 DE102017122227 A1 DE 102017122227A1
Authority
DE
Germany
Prior art keywords
peer
device
key
application
record
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.)
Pending
Application number
DE102017122227.8A
Other languages
German (de)
Inventor
Carsten Stöcker
Harald Kemmann
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Innogy Innovation GmbH
Original Assignee
Innogy Innovation GmbH
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Innogy Innovation GmbH filed Critical Innogy Innovation GmbH
Priority to DE102017122227.8A priority Critical patent/DE102017122227A1/en
Publication of DE102017122227A1 publication Critical patent/DE102017122227A1/en
Application status is Pending legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06KRECOGNITION OF DATA; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K9/00Methods or arrangements for reading or recognising printed or written characters or for recognising patterns, e.g. fingerprints
    • G06K9/00577Recognising objects characterised by unique random properties, i.e. objects having a physically unclonable function [PUF], e.g. authenticating objects based on their unclonable texture
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/12Payment architectures specially adapted for electronic shopping systems
    • G06Q20/123Shopping for digital content
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/22Payment schemes or models
    • G06Q20/223Payment schemes or models based on the use of peer-to-peer networks
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices
    • G06Q20/36Payment architectures, schemes or protocols characterised by the use of specific devices using electronic wallets or electronic money safes
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network-specific arrangements or communication protocols supporting networked applications
    • H04L67/10Network-specific arrangements or communication protocols supporting networked applications in which an application is distributed across nodes in the network
    • H04L67/104Network-specific arrangements or communication protocols supporting networked applications in which an application is distributed across nodes in the network for peer-to-peer [P2P] networking; Functionalities or architectural details of P2P networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network-specific arrangements or communication protocols supporting networked applications
    • H04L67/12Network-specific arrangements or communication protocols supporting networked applications adapted for proprietary or special purpose networking environments, e.g. medical networks, sensor networks, networks in a car or remote metering networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communication
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0866Generation of secret information including derivation or calculation of cryptographic keys or passwords involving user or device identifiers, e.g. serial number, physical or biometrical information, DNA, hand-signature or measurable physical characteristics
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communication
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communication 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communication
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communication 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/3236Cryptographic mechanisms or cryptographic arrangements for secret or secure communication 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/3239Cryptographic mechanisms or cryptographic arrangements for secret or secure communication 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communication
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communication 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/3271Cryptographic mechanisms or cryptographic arrangements for secret or secure communication 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 challenge-response
    • H04L9/3278Cryptographic mechanisms or cryptographic arrangements for secret or secure communication 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 challenge-response using physically unclonable functions [PUF]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements, e.g. access security or fraud detection; Authentication, e.g. verifying user identity or authorisation; Protecting privacy or anonymity ; Protecting confidentiality; Key management; Integrity; Mobile application security; Using identity modules; Secure pairing of devices; Context aware security; Lawful interception
    • H04W12/06Authentication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/12Details relating to cryptographic hardware or logic circuitry
    • H04L2209/127Trusted platform modules [TPM]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/38Chaining, e.g. hash chain or certificate chain
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30Services specially adapted for particular environments, situations or purposes
    • H04W4/40Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70Services for machine-to-machine communication [M2M] or machine type communication [MTC]

Abstract

The application relates to a system (100, 200, 300, 500) comprising at least one device (102, 202, 302) with at least one output device (106, 206, 306) configured to output at least one data set and at least one A PUF device (104, 204, 304) arranged to generate at least one uniquely assigned key of the device (102, 202, 302), wherein the key is used in outputting the data set, at least one peer-to-peer network (110 , 210, 310, 510) comprising at least one peer-to-peer application (114, 214, 314, 414), and at least one at least one controlled by the peer-to-peer application (114, 214, 314, 414) Key registers (118, 218, 318, 418) arranged to at least store the key uniquely assigned to the device (102, 202, 302), the peer-to-peer application (114, 214, 314, 414) comprising at least one of at least part of the peer computers (112, 212, 312, 502, 512, 564) of the peer-to-peer network and authenticity module (116, 216, 316, 416) for checking the key used in the output of the record based on the key register (118, 218, 318, 418) after receiving the record by the peer-to-peer application (114, 214, 314, 414).

Description

  • The application relates to a system, in particular an authenticity system, with at least one device, comprising at least one output device, configured at least for outputting at least one data record. In addition, the application relates to a method, in particular for monitoring the data exchange in a system according to the application, a device, in particular for a system according to the application, and a peer-to-peer application for a system according to the application.
  • Sensor devices, but also other devices, of communication systems are set up to transmit data records comprising comprehensively captured parameter values to at least one central entity, in particular a server, via a communications network. A constant concern is to ensure that a record output by a sensor device through an output device and transmitted to the server is not tampered with.
  • To prevent manipulation of a record, the use of cryptographic keys is known. In particular, the outputting or transmission of a data record can take place using a cryptographic key which is assigned to the device.
  • A known and considered particularly safe device that can be used as a key generator is a so-called PUF device (Physical Unclonable Function Device). In the present case, a PUF device is characterized in that a (specific) key (in the form of a bit sequence), also called a response, is dependent on an input signal (in the form of a bit sequence), also called a challenge, and dependent on the physical properties of the PUF device, can be generated by the PUF device. Since the physical properties are inherent in the manufacturing process and are clearly associated with the fabricated device, it is not possible to duplicate the device.
  • However, the conventional solutions of the prior art have several disadvantages. Thus, a central instance in the form of a server (or several servers) is always required, in which the keys are stored. In addition to the high transaction costs, which arise through a corresponding communication architecture, another disadvantage of this architecture is that the central entity or the central server key data, but also other sensitive data, such as user data (account data, access data, consumption data, etc.) manages , A constant problem of the central authority is to protect these data stored on one or more servers / n from access by an unauthorized third party. In particular, a great safety effort is required to prevent manipulation of, for example, the user data, billing data, detected parameter values, etc. This in turn leads to higher transaction costs.
  • Therefore, the object of the application is to provide a system for outputting data records, which allows manipulation-proof data exchange.
  • The object is achieved according to a first aspect of the application by a system, in particular authenticity and / or communication system, according to claim 1. The system comprises at least one device with at least one output device, configured for outputting at least one data record, and with at least one PUF device, configured to generate at least one (PUF) key uniquely assigned to the device. The key is used when outputting the record. The system comprises at least one peer-to-peer network comprising at least one peer-to-peer application. The system comprises at least one key register at least controlled by the peer-to-peer application, set up at least for storing the key uniquely assigned to the device. The peer-to-peer application comprises at least one authenticity module executable by at least a portion of the peer-to-peer peer computers. The authenticity module is for checking the key used in the output of the record based on the key register upon receipt of the key Set up by the peer-to-peer application.
  • In contrast to the prior art, it is provided according to the application that when a data set is output by a device, a key generated by a PUF device of the device is used and a record output in this manner is monitored by an authenticity module of a peer-to-peer application. is evaluated. In particular, the manipulation security is achieved by the combination of a PUF device according to the application and the authenticity module that can be executed essentially simultaneously by a part (> 1) of the peer computer. By instead of a central server or a platform a peer-to-peer network (ie a framework), at least a part (> 1) of the peer computers of the peer-to-peer network, at least performs the monitoring or evaluation, the safety is improved significantly and in a simple way. In a peer-to-peer network according to the application, high security standards are achieved by preferably all peer computers (peer nodes or peers) of the network, at least a subset of the peers of the network, monitor the correctness of the key used. The transaction costs can be significantly reduced. There is no central, parent platform, server, cloud, etc. required. Only if this part of the peer computer reaches a positive authenticity result can the authenticity and / or authenticity of the data record or of the data record comprising the data record be verified. An additional crypto chip can be dispensed with.
  • The system according to the application is, in particular, a communication system with at least one (first) device which can output data records or send out data records. For this purpose, the device according to the application has at least one output device configured to output at least one data record. The output device may be configured, for example, to transmit a message with the data record via a wired and / or wireless communication network.
  • In addition, the device comprises a so-called PUF device (Physical Unclonable Function Device). In the present case, a PUF device is characterized in that a (specific) key (in the form of a bit sequence), also called a response, is dependent on an input signal (in the form of a bit sequence), also called a challenge, and dependent on the physical properties of the PUF device, can be generated by the PUF device. The key can be called a PUF key. In particular, this key represents the identity, in particular the PUF identity, of the device. Since the physical properties are inherent in the manufacturing process and are clearly associated with the fabricated device, it is not possible to duplicate the device. For example, the challenge may configure a chip or other device according to the challenge bit sequence. By means of a measuring mechanism of the PUF device, the state of the chip or the other device caused by the configuration can be measured and output as a response (in the form of a bit sequence).
  • Exemplary and non-terminating PUF devices include non-electronic PUFs (eg, Paper PUF, CD PUF, Optical PUF, Optical Integrated PUF, RF-DNA PUF, Magnetic PUF, Acoustic PUF, etc.), analog electronic PUFs (eg, VT PUF, Power Distribution PUF, coating PUF, LC PUF, etc.), "delay-based intrinsic" PUFs (eg Arbiter PUF, XOR Arbiter PUF, Ring Oscillator PUF, etc.) and memory-based intrinsic PUFs (eg SRAM PUF, Butterfly PUF, Latch PUF, Flip-flop PUF, etc.).
  • When issuing or sending the data record, in particular for each data record, the at least one key generated is used. In particular, the record or the corresponding message can be provided with the key. This is to be understood in particular that the data record can be identified as originating from the device. The key is uniquely associated with the sending device due to the use of a PUF device. This makes it possible to detect the exchange of a device or its manipulation due to another key and / or to prevent "man-in-the-middle" attacks.
  • Furthermore, the system according to the application comprises at least one peer-to-peer network with at least one peer-to-peer application. Compared to a client-server network in which a server offers a service and a client uses this service, this role distribution is eliminated in a peer-to-peer network. Each participant in the peer-to-peer network can use a service equally and offer it themselves. In particular, a peer-to-peer network is self-determined and / or self-organized (without a higher-level unit). In the present case, preferably each computer or peer of the peer-to-peer network has a peer-to-peer application.
  • At least one key register is provided according to the application. The key register is set up at least for storing the key that can be generated by the at least one PUF device. In particular, at least one challenge / response pair (CPR) of the at least one device and / or at least one parameter for the PUF authentication protocol of the at least one device can be stored in the key register as a key. Preferably, a challenge / response pair, preferably a plurality of challenge / response pairs (with different challenges and correspondingly different responses) may be stored for each PUF device registered in the key register. In particular, (thereby) the at least one (PUF) device identity may be stored in the key register. In addition to the device identity, further master or movement data may preferably be stored in the key register or in a digital product memory (in a decentralized data memory).
  • The key register is at least controllable by the peer-to-peer application. In one embodiment, it is to be understood that the key register may be included as a key register module from the peer-to-peer application. In other words, the key register module may be at least part of the peer computer be saved. In particular, this part may comprise at least the part which also comprises the authenticity module. Upon execution of the authenticity module, therefore, the key register can be accessed (immediately). As a result, the security can be further improved because for successful manipulation all key registers would have to be manipulated at least by this part of the peer computer.
  • Alternatively or additionally, this is understood to mean that the peer-to-peer application has a control module configured to control and / or control access to a, in particular decentralized, data storage arrangement. Preferably, the storage device, which may include a plurality of remote storage devices, may be a distributed database system (such as IPFS) or a distributed object store (such as storj) or a distributed distributed database (such as BigchainDB) that is the peer -to-peer application is controlled. For example, the peer-to-peer application may include a suitably configured control module executable by a portion of the peer computer.
  • The peer-to-peer application, in particular a software application, comprises at least one authenticity module. The authenticity module, when executed, is set up to check the key used in issuing a record. For example, the record may be transmitted directly or indirectly to the peer-to-peer application. For example, after a reception and in particular before further processing of the data record, the authenticity of the data record can be carried out by an authenticity check of the at least one used key based on the key register, ie in particular the keys stored therein (for example challenge-response pairs). This may include, for example, performing at least one comparison operation between received keys and stored keys. Only if a correspondence between the key used and a stored key is determined by the part of the peer computer due to the execution of the authenticity module, further processing of the corresponding data record can be permitted. Otherwise, further processing of the corresponding data record can be blocked and this can be marked accordingly, for example. Further measures, e.g. to check the cause, can be arranged.
  • In particular, by means of the PUF key, the issuing device can be uniquely identified.
  • According to a first embodiment of the system according to the application, the device can be formed as a sensor device with at least one sensor device. The sensor device can be set up to detect at least one parameter. The output data set may in particular comprise at least the detected parameter value. The sensor device may be, for example, a sensor for taking a measurement (e.g., amount of heat, temperature, humidity, pressure, sound field size, brightness, acceleration, pH, ionic strength, electrochemical potential, etc.). The detected parameter values can be output by the sensor device through an output device in the form of at least one data record. By incorporating the PUF device in the sensor device, manipulating the key can at least significantly hinder manipulation of the output parameter values.
  • Alternatively or additionally, the device may be formed as an actuator device with at least one actuator device. The actuator device can be set up to move an actuatable element. In particular, the output data set may comprise at least one state of the actuator device and / or of the actuatable element. In the present case, a method of an actuatable element is to be understood in particular as meaning that an actuator transmits, in particular, a command data record (or signal) provided in mechanical motion and / or other physical variable (s). In this way, in particular, an actuatable element can be moved or adjusted in accordance with the mechanical movement and / or a different physical variable. For example, state data about the actuator and / or the actuatable element can be obtained from the actuator device by a Output device in the form of at least one record to be output. By incorporating the PUF device in the actuator device, manipulating the key can at least significantly complicate manipulation of the output data sets.
  • Alternatively or additionally, the device may be formed as a processing device with at least one processing device. The processing device can be set up to process receivable data. In particular, the output data record may comprise at least the processed data. For example, an electronic chip or the like may be provided as a processing device. Data, such as datasets, comprising parameter values described above, which have been detected by a sensor device, can be processed by the processing device. The processed data may be output by the processing device through an output device in the form of at least one record. By incorporating the PUF device into the processing device, manipulating the key can at least significantly hinder manipulation of the output data sets.
  • In the event that the processed data are captured parameter values previously provided with a first key of the corresponding sensor device, the data record output by the processing device may be associated with at least two keys, in particular the previously received key of the Sensor device, and the key of the processing device, be provided. In a subsequent authenticity check of such a record, the authenticity module is set up to check the two keys. Only if a positive authenticity result is determined for both keys, further processing of the data record can be permitted. It is understood that three or more further device can be interposed. In other words, preferably one device may receive a keyed record from another device. When outputting the data record - for example in order to forward the data record - the device can additionally provide the data record provided with the key with its own key in accordance with the previous statements. When verifying the record then both keys, generally all keys of a record, are checked by the authenticity module.
  • It is understood that the various devices of a device may be formed by a compact unit, such as a chipset. In this case, the device may comprise a housing which preferably encloses all the devices of a device. Manipulation can be further complicated.
  • According to a particularly preferred embodiment of the system according to the application, the system may comprise at least one peer-to-peer module. The peer-to-peer module can be set up, at least for transferring the record used to the key to the peer-to-peer application. The peer-to-peer module is set up in particular for communicating with the at least one peer-to-peer application. The peer-to-peer module may for example be associated with a device, such as a sensor, actuator, and / or processing device. Also, it may be formed by a separate device connectable to another device, such as a sensor, actuator, and / or processing device.
  • For example, a device according to the application may comprise a peer-to-peer module. For example, the peer-to-peer module can be integrated in the at least one device of the system according to the application. In this case, the peer-to-peer module may be formed by the output device of the device. In this case, the peer-to-peer module may particularly preferably comprise the PUF device.
  • It is also possible for a communication connection to be provided between a device and a (remote) peer-to-peer module, which is allocated in particular to this device. This means, in particular, that the peer-to-peer module can communicate and / or act at least in the name of this device. For example, the peer-to-peer module may be partially formed by a separate processing unit, such as a mobile communication device (eg, cellular phone, mobile computer, etc.), or on a remote, stationary processing unit (e.g., a data center). In the case of a mobile processing unit or a remote stationary processing unit, the at least one device may include a secure communication channel to the processing unit (or mobile communication device) of the data center, and the processing unit itself may provide a connection to the peer-to-peer network. In one embodiment, the remote processing unit may be a "gateway" to the peer-to-peer network. This means that the device can securely communicate with the peer-to-peer network via the associated peer-to-peer module and the gateway formed thereby.
  • Preferably, the device may comprise at least one signing device. Particularly preferably, the signing device (and the PUF device) can be integrated in the output device of the device. As a result, the security against manipulation is further increased. The signing device can be set up to sign the output data record using the key uniquely assigned to the device. Signing means, in particular, that the data record is provided with a signature (or certificate) based on the key (in particular, the key forms the signature). As a result, the authenticity (or authenticity) of the data can be confirmed.
  • Alternatively or additionally, according to a further embodiment, the device may comprise at least one encryption device. Particularly preferably, the encryption device (and / or the PUF device and / or the signing device) can be integrated in the output device of the device. This will be the Manipulation security further increased. The encryption device may be configured to encrypt the output data set using the key uniquely assigned to the device. If both a signing device and an encryption device are provided, the PUF device may preferably generate two keys (based on different challenges). A first key can then be used for signing and another key for encryption. Alternatively, other encryption concepts can be used.
  • Alternatively or additionally, according to a further embodiment, the device may comprise at least one grasping device. The hash device may be integrated in the output device. The hash device may be configured to hash at least one output record. In other words, the outgoing data can be hashed. Their hash may preferably be stored in the key register of the peer-to-peer application. As a result, in particular the integrity of transmitted data can be confirmed. Alternatively or additionally, a MAC or HMAC protocol may be used.
  • Moreover, according to a preferred embodiment, the peer-to-peer application may comprise at least one register module. The register module may preferably be executable by at least part of the peer-to-peer peer computers. The register module can be set up to register a (new) device in the key register at least by storing the key uniquely assigned to the device, for example at least one challenge-response pair. Particularly preferably, the registration can be carried out during or immediately after the device has been manufactured. In addition to the at least one key, further data relating to the device can be registered (digital product memory), such as manufacturer, owner, installation location, status, data on the manufacturing process (for example, materials used, machines, etc.), identifier, etc.
  • The register module can be configured to receive a registration message from a device, in particular from a peer-to-peer module assigned to this device. The registration message may preferably comprise at least the key, in particular the at least one (preferably several) challenge-response pair. The register module may be configured to store at least the one key in the key register to register the device.
  • Prior to registering a device, at least a portion of the peer-to-peer network peer computers, in particular by running the register module, may check to see if the registration requirements (eg, specific entity specifications or valid keys or compliance requirements) are predefined by the peer-to-peer network, are met by the device requesting registration. For example, the key, in particular the at least one challenge-response pair, can be checked by carrying out a communication test (for example exchange of test messages, in particular in the form of challenges).
  • Alternatively or additionally, it may be necessary for a device to meet predefined, technical specifications. To perform the check, further data may preferably be included in the registration message. In particular, the peer-to-peer network peer computers may specify registration rules or registration requirements that must be met by a device in order to be considered, in particular, as a trusted device. Rules and / or requirements may be defined individually by the peer computers of a peer-to-peer network. For example, it may be necessary for a new device to be recommended by an entity that is already a peer-to-peer network peer. In addition, it may be necessary for this participant to have a reputation factor that exceeds a predefined minimum reputation factor.
  • The system may be at least partially integrated in a vehicle. Exemplary and non-terminating vehicles are automobiles, trucks, ships, railcars, aircraft, bicycles, motorcycles, drones, mobile machines, boats, airplanes, submarines, spacecraft, satellites, etc.
  • The system may be at least partially formed by the electrical system of such a vehicle. In particular, the sensors, actuators and / or processing units (for example ECU) used in an on-board vehicle network (or in several vehicle on-board networks) can be formed by previously described sensor devices, actuator devices and / or processing devices. In this way, for example, the manipulation of vehicle parameter values, such as speed data, acceleration data, consumption data, etc., can at least be made more difficult. Corresponding data records can, for example, be transmitted to the peer-to-peer application and / or another entity for further evaluation.
  • Preferably, the on-board network of a vehicle may itself be organized in the form of an internal peer-to-peer network (eg peer-to-peer modules in the different ECUs of a vehicle or other electronic system components). This peer-to-peer network can communicate with an external peer-to-peer network. Both peer-to-peer networks can each have a previously described peer-to-peer application comprising at least one authenticity module. Preferably, a plurality of on-board networks each communicate in the form of a peer-to-peer network according to the application with an external peer-to-peer network. For example, at least one device of the internal peer-to-peer network may also be a peer computer of the external peer-to-peer network.
  • In addition, the system may be at least partially integrated in a home automation system. In particular, the sensors, actuators, and / or processing units (e.g., home automation controllers) employed in a home automation system may be constituted by previously described sensor devices, actuator devices, and / or processing devices. As a result, for example, the manipulation of house parameter values, such as temperature data, presence data, consumption data, etc., can at least be made more difficult. Corresponding data records can, for example, be transmitted to the peer-to-peer application and / or another entity for further evaluation.
  • According to the above remarks on a vehicle electrical system, the home automation system or network can also be organized as a peer-to-peer network and communicate, for example, with another external peer-to-peer network.
  • Moreover, the system may be at least partially integrated in an infrastructure network or its individual components, e.g. Components of utility networks, monitoring networks, traffic management networks, measuring networks (for example meteorological monitoring networks), logistics networks, production networks, etc.
  • In addition, according to another embodiment, the system may include at least one authentication device with at least one authenticity module. In particular, the authentication device (eg, handset) may be configured to, in the event of a non-existent instantaneous connection to the peer-to-peer network (eg, due to a network error) of the key used in the output of the record based on a further key register stored in the authentication device Receive the record. Even in an offline case, the authentication of a device with a PUF device can be performed. Preferably, in an authentication device obfuscating PUF protocols can be used to keep the amount of data on the authentication device small.
  • According to one embodiment of the system according to the present application, the peer-to-peer application may be a distributed register, a distributed ledger or a shared database. The decentralized register may be readable by at least each participant in the peer-to-peer network. In particular, all peer-to-peer modules and all peer-to-peer peer computers may preferentially receive all the information in the peer-to-peer application (or peer-to-peer application controlled memory arrangement) read. Preferably, all peer-to-peer modules and all other computers or peer computers of the peer-to-peer network can send messages or data records to the peer-to-peer application or write to them. In a simple way, information can preferably be made accessible to all subscribers of the peer-to-peer network. This makes it possible to carry out a check of the information stored in the decentralized register, as previously described records, key register entries, etc. In particular, each peer computer of the peer-to-peer network can be set up, a check of new information, in particular based on older ones information stored in the peer-to-peer application.
  • In addition, according to a further embodiment of the system according to the application, each peer (subscriber) of the peer-to-peer network can have the peer-to-peer application. Preferably, each computer, at least part of the peers, each comprise the complete data content, but at least part of the data content of the peer-to-peer application, in particular of the decentralized register. For example, it can be provided that, after a positive verification of a new information written in the peer-to-peer application, it is stored by all peer computers, at least by a part of the peer computers. The manipulation security can be further improved thereby.
  • In order to save new information in a tamper-proof manner, the peer-to-peer application may comprise encryption means and / or signature means and / or verification means, for example suitable hash functions. At least one means of the aforementioned means can be set up for storing, in particular, at least each generated data record. In particular, can be provided that the linkage with at least one previous information stored in the decentralized register is established by the hash function. Other data such as requests, root, context and / or transaction data of a device or user may be stored.
  • In a particularly preferred embodiment, the peer-to-peer application may be a blockchain or a remote ledger comprising at least two blocks linked together. The blockchain technology or "decentral ledger technology" is already used when paying by means of a crypto currency, such as Bitcoin. It has been recognized that a blockchain can be set up by means of a special configuration to control at least one data exchange particularly tamper-proof.
  • The blockchain according to the present embodiment is in particular a decentralized, peer-to-peer based register in which preferably a plurality of data sets and / or modules and other messages of device (s) may be logged. A blockchain as a technical means is particularly suitable for replacing a central instance in a simple and secure manner.
  • As already described, the at least one peer-to-peer application may be a decentralized register, a distributed ledger or a shared database configured to store data, e.g. the previously described records, identifier (s), keys, etc. with certain proofs and / or signatures. In addition to e.g. Keys of registered devices, the decentralized register may store computer code, e.g. the authenticity module for monitoring the authenticity of a data set or a register module for registering a device or a control module for controlling access to a data storage device controlled by the control module.
  • In particular, the code can be called by a transaction to the address of the code in the so-called "smart contract". This code can be processed on the majority of peer-to-peer peer computers.
  • It will be appreciated that a smart contract code or processing logic may be stored and executed in so-called "crypto condictions" of the interledger protocol (ILP), which means that not all of them Code must be stored in a smart contract, such as Ethereum smart contract.
  • In another embodiment, the (smart contract) code may be stored and executed on a remote computing marketplace (eg, Ethereum Computation Market, Trubit, Golem, Microsoft Cryplets).
  • In another embodiment, computer code of an external computing device controlled by the peer-to-peer application may include distributed cognitive analysis, artificial intelligence, or machine learning algorithms. Analytics and learning can be shared with other devices and shared, aggregated, and analyzed through the peer-to-peer application. For example, these algorithms can be used to optimize an exchange process.
  • A decentralized register may be readable by at least part of the peer-to-peer network participants. In particular, each computer node (peer computer) and each registered entity / device (by means of the respective peer-to-peer module) may comprise the peer-to-peer application. The remote register, at least the public part (i.e., without private contracts), can be read by at least each participant in the peer-to-peer network. In particular, all peer-to-peer modules and all other peer-to-peer peer computers can preferably read all the information in the peer-to-peer application, which is designed as a register. Preferably, it is also possible that all peer-to-peer modules and all other peer-to-peer peer computers can send or receive messages / records to the peer-to-peer application. A message or transaction sent to a smart contract may start executing a code of the smart contract (eg, authenticity module, register module, etc.) while using data stored in the smart contract. For example, receiving a record may start execution of the authenticity module as described above. Also, a registration message may start the execution of the register module.
  • The peer-to-peer application can be based on the following elements: peer-to-peer network with Consensus System / Protocol, Data Structure, Merkle Trees, Public Key Signatures and / or Byzantine Fault Tolerance. It can replicate data according to a consensus principle. It can be auditable and traceable.
  • In a simple way, information can preferably be made available to all participants. This can be a check of the information stored in the decentralized register or the codes executed in the decentralized register enable. Particularly preferably, each computer (peer computer) can be configured in the peer-to-peer network to check new information, in particular on the basis of older information stored in the peer-to-peer application. In addition, the at least one authenticity module and / or the at least one control module and / or the at least one register module can be monitored by at least part of the peers of the peer-to-peer network, preferably by all peers. Manipulation of such a module can thus be prevented.
  • In addition, at least one peer computer, preferably each peer computer, each comprise the complete data content, but at least part of the data content of the peer-to-peer application, in particular the decentralized register include. For example, it may be provided that after a positive authentication of a data record or e.g. after a positive registration of a device in the peer-to-peer application, this information is stored by all peer computers, at least some of the peer computers. For example, after a successful registration of a device, the at least one (new) key can be stored at least by a part of the peer computers, preferably by all the peer computers of the peer-to-peer network. Tamper protection for the data stored in the peer-to-peer application can thus be further improved. A data exchange process and / or a registration process can be securely controlled.
  • The peer-to-peer application may be formed by a Directed Acyclic Graph (DAG). A directed acyclic graph, such as IOTA or Tangle, means that blocks (or nodes of the graph) are coupled together via directed edges. "Direct" means that the (all) edges (always) have the same direction in time. In other words, it is not possible to go back. After all, acyclic means that loops do not exist.
  • In other embodiments of the peer-to-peer application, the blockchain may be a "permissionless" or "permissioned" blockchain. In one case, the blockchain may be a public, consortium, or private blockchain.
  • In a further embodiment, several peer-to-peer networks, in particular blockchains, can be provided, which are connected via mechanisms such as "side chains" or smart contracts. In particular, this makes it possible for at least one external peer-to-peer network described above to be connectable to at least one internal peer-to-peer network of a vehicle or a building as described above. A peer-to-peer node or peer computer can execute one or more blockchain client (s).
  • The data of the peer-to-peer application may be stored on the "decentralized Ledger technology" and / or the "decentralized Ledger-Steers (encrypted) data storage" via the Internet and preferably in the decentralized data storage, object storage or database, such as z. An interplanetary file system (IPFS) or storj, or in a distributed blockchain database (e.g., BigChainDB or a database hashed with Cryptowerk functions). Access to encrypted data to third parties may be managed via a previously described control module, which may be formed as one or more smart contracts in the blockchain.
  • Also, tokens from a peer-to-peer network may be frozen and e.g. be transferred to a block-authenticated database. That Users can have a second 'wallet' in this database. Transactions between the users or their wallets can be performed as high-performance database transactions. After a certain time or the completion of the entire transaction, the result can be written back to the original peer-to-peer network. As an example of the execution of multiple blockchains, an IoT blockchain, such as DAT tangle, can be used to securely capture IoT data, and store it in a second peer-to-peer network, such as a peer-to-peer network. BigchainDB, as input for the execution of transactions store.
  • In addition, data feeds may be provided by the peer-to-peer application (called smart oracles). Data feeds may provide additional data via a device from at least one other source. Data may be received from trusted sources and stored in the peer-to-peer application or stored via the peer-to-peer application on a remote data storage device.
  • Information between peer computers can be exchanged through a peer-to-peer messaging system. This means that a peer computer can send a message to another peer computer to convey information or initiate an action. Messages or records can be plain text, signed, hashed, time stamped and / or encrypted. This means that not all data exchanged between peers must be stored on the peer-to-peer application.
  • In a further embodiment, the at least one peer-to-peer network may be formed by a plurality of peer computers and a peer-to-peer module. A peer-to-peer module can only be configured to communicate with the multitude of peer computers. In other words, the peer-to-peer module is not a peer-to-peer peer, it is just a participant. Such a peer-to-peer module does not include the peer-to-peer application, but provides only an interface module, such as an application programming interface (API), and a remote application for communicating with the peer-to-peer peer computers Network or with the peer-to-peer application, such as a blockchain or a smart contract of a peer-to-peer application. For example, such a peer-to-peer module can either send plaintext or encrypted information or create a secure connection (eg tunnel) to another peer-to-peer module to communicate with the peer-to-peer module or peer -to-peer network to communicate. This allows a reduction in the required computing power of the peer-to-peer module.
  • In one embodiment of the peer-to-peer network, there may be only one validating peer computer or one complete node, e.g. Only one node can be configured to perform a validation process and one or more observation (or monitoring) peers. An observation spear can validate some transactions to establish a trust level, but it does not validate all transactions performed by the validating peer.
  • In another embodiment, the peer-to-peer module may be one of the peer computers. In this case, the peer-to-peer module comprises at least part of the peer-to-peer application. In particular, the peer-to-peer module may preferably comprise the entire data content of the peer-to-peer application or access the information stored in another peer. For example, the peer-to-peer module may be a so-called "light node" or a distributed application (DAPP) connected to a remote peer (fixed).
  • It is noted that in the present case, in one embodiment, the peer-to-peer module includes at least one API configured to communicate with the peer-to-peer application. In addition to the API, the peer-to-peer module includes a distributed software application that includes local algorithms that are at least configured to store records, such as records. Measurement data to generate and transfer via the API to the peer-to-peer application. The distributed Dapp application is at least configured to process and transmit the data.
  • Preferably, the data is signed or encrypted or can be transmitted via a cryptographically secured tunnel or a secure Internet connection to a peer or another peer-to-peer module. In another embodiment, the peer-to-peer application itself is also implemented in the peer-to-peer module, i. the peer-to-peer module is a peer to the peer-to-peer network that includes the distributed application, the API, and the peer-to-peer application.
  • Data and transactions stored on the blockchain do not provide "transactional privacy." Transactions between pseudonyms can (often) be stored in plain text on the blockchain. In some cases, the data stored on the blockchain is encrypted and the keys can be handled via the blockchain. Transactions between aliases are stored in plain text on the blockchain. Secure transactions or executions of computer codes can be performed with cryptographic tools, such as. For example, "zero knowledge" (zk) proofs or "zk succinct non-interactive arguments" (zk-SNARK) can be achieved. Transactions or algorithms are divided into two parts: a smart contract via the blockchain and a private contract. A privacy protection protocol ensures the privacy of the data and the correctness of the code execution (SNARK verification is done via the smart contract on chain). The private order calculation can be performed by a set of peers, OffChain computers, or in a "measured launch environment" or a secure hardware enclave for certification and sealing that is not executed by any other software code running on the devices will be able to be manipulated. In an alternative embodiment, secure multi-party computing (sMPC) systems may be used for transaction privacy. Examples of privacy protection protocols and calculations are HAWK and MIT Enigma.
  • With "zero knowledge" (zk proofs) the parties can see that the algorithm is executed correctly in a private contract, but the input data is not passed on to the parties. In addition, selective privacy can be provided by releasing transaction decryption keys for reporting and auditing purposes.
  • To securely deliver codes and / or data to a device, a trusted execution environment (Trusted Execution Environments) such as Intel SGX or TPM or Direct Anonymous Attestation module with a peer-to-peer module. In further embodiments, a PUF device may be integrated in a trusted execution environment.
  • Also, other cryptographic methods may be used to establish transactional privacy (e.g., ring signatures, stealth addresses, or pedersen commitments).
  • Similarly, in another embodiment, a particularly large peer-to-peer network may be split into two or more (physical or logical or dynamic virtual) clusters. For example, in a corresponding peer-to-peer network, validation (a subset of transactions) can only be performed by the members of a cluster (a subset of peers, eg, partitioning a blockchain to improve scalability). In another embodiment, the peer-to-peer application may be formed using multiple blockchains. These blockchains are linked via frameworks such as sidechains or smart contracts or interledger protocols.
  • Another aspect of the application is a method comprising:
    • Outputting at least one data record by an output device of a device using at least one key assigned to the device,
    • the key being generated by at least one PUF device integrated in the device,
    • Providing a peer-to-peer application of a peer-to-peer network,
    • - Providing a controlled at least by the peer-to-peer application key register, set up at least for storing the device uniquely assigned key, and
    • Checking the issued and received by the peer-to-peer application record by executing at least one authenticity module through at least part of the peer-to-peer peer computers,
    • - wherein the checking comprises evaluating the key used in the output of the record based on the key register.
  • The method can be carried out in particular on a system described above. In particular, the checking step comprises verifying the authenticity of a received data record based on the at least one key used and the stored keys.
  • In the present application, a key that is used when outputting a data record is to be understood as meaning a PUF key generated by the issuing device.
  • Another aspect of the application is a device. The device comprises at least one output device, configured to output at least one data record. The device comprises at least one PUF device, configured to generate at least one key uniquely assigned to the device. The key is used when outputting the record. The output device is formed by a (previously described) peer-to-peer module, configured at least for transmitting the data set used to the key to a peer-to-peer application of a peer-to-peer network such that at least one peer-to-peer authenticity module executable by at least a portion of the peer-to-peer peer computers checks the key used in the output of the record based on a key register storing the key.
  • The device can be implemented in particular in a system described above. In particular, the device may be a previously described sensor device, a previously described actuator device and / or a previously described processing device.
  • Yet another aspect of the application is a peer-to-peer application, in particular a peer-to-peer application described above, for a peer-to-peer network (described above), comprising:
    • at least one authenticity module executable by at least a part of the peer-to-peer peer computers, configured to verify a record received by the peer-to-peer application and output using a key generated by a PUF device,
    • - Wherein checking comprises evaluating the key used in the output of the record based on a peer-to-peer application at least controlled key register, set up at least for storing the device uniquely assigned a key.
  • The peer-to-peer application may, in particular, be a processor program that can be executed on a processor.
  • The system according to the application can be used, for example, for software licensing applications or anonymous computing applications. The system according to the application can also be used for software updates of systems and / or their parameterization. A preferred application may be the over-the-air updates of systems (vehicles, buildings, infrastructure network, etc.).
  • Furthermore, a distinction can be made between so-called weak and strong PUF facilities. A strong PUF facility may differ (among others) from a weak PUF facility with a higher number of challenge-response pairs (CPR). In preferred embodiments of the application, strong PUF equipment can be used.
  • Furthermore, a PUF device can be combined with a crypto hardware processor. For example, this combination may be arranged to generate a stronger key from a weak key and / or Keyed-Hash Message Authentication Code Generation (HMAC) to establish sufficient authentication capability to authenticate messages from a device to a third party ( and thus to prevent man-in-the-middle attacks), and / or for signing, hashing and / or encrypting messages.
  • Preferably, so-called hardware Entangled Cryptography can be applied, in which a PUF device can be integrated into the crypto-hardware processor (or vice versa).
  • Also, a PUF device may also be combined with an error-correction module that can correct for variances in responses (e.g., due to temperature dependencies of devices) in CPRs. In particular, in order to avoid repetition, a PUF device is in particular a device with or without a crypto-hardware processor and / or with or without error correction modules.
  • A PUF device is furthermore to be understood to mean a device which represents a so-called "physical one-way" function which generates one or more responses from one or preferably several challenges, which are different from the individual, special ones depend on physical properties of a device. Such a mechanism may be arranged to produce one-way functions, to produce cheaply, to be extremely expensive (or even impossible to duplicate), primarily not based on mathematical algorithms and tamper-resistant. These functions can be used for an authentication protocol. Functions can be used that enable a large address space or a large amount of CPRs. Other examples of PUF facilities are Physical One Way Functions, Physical Random Functions or Continuously Variable Quantum Authentication of Physical Unclonable Keys. These methods can be at least partially implemented in a PUF device and in particular be summarized under the term PUF. Furthermore, there are variances of PUFs, e.g. t-PUFs.
  • Also, the method of obfuscating PUFs, in which not a larger amount of CPRs in a key register, but only a relatively smaller record must be stored and for this protocol arithmetic operations must be performed on the device, in a PUF device according to the application be at least partially implemented. In addition to authentication, PUFs can still be used for secret key generation and key storage.
  • A PUF device is also to be understood as physically obfuscated keys (POK) and physically obfuscated algorithms devices. Keys can not be stored electronically but physically.
  • In such controlled PUF (CPUF) devices, a PUF device can be used in combination with cryptographic primitives. In particular, such a CPUF can only be accessed via an algorithm physically linked to the PUF.
  • Reconfiguarbale PUF (rPUF) facilities can be reconfigured to change the CRP behavior randomly and irreversibly in a reconfiguration process. Other PUF concepts include Quantum Readout PUFs, SIMPL Systems and PPUFs.
  • All of the above-mentioned concepts / devices are in the present application in particular under the term PUF together.
  • The features of the systems, methods, devices, peer-to-peer applications and computer programs are freely combinable. In particular features of the description and / or the dependent claims, even in complete or partial circumvention of features of the independent claims, in isolation or freely combined with each other independently be inventive.
  • There are now a multitude of possibilities for designing and further developing the system according to the application, the method according to the application, the device according to the application and the peer-to-peer application according to the application. For this purpose, reference is made, on the one hand, to the claims subordinate to the independent patent claims, and, on the other hand, to the description of exemplary embodiments in conjunction with the drawing. In the drawing shows:
    • 1 a schematic view of an embodiment of a system according to the present application,
    • 2 a schematic view of another embodiment of a system according to the present application,
    • 3 a schematic view of another embodiment of a system according to the present application,
    • 4 a schematic view of an embodiment of a peer-to-peer application according to the present application;
    • 5 a schematic view of another embodiment of a system according to the present application;
    • 6 a diagram of an embodiment of a method according to the present application;
  • In the figures, like reference numerals are used for like elements.
  • The 1 shows a schematic view of an embodiment of a system 100 , in particular a communication system 100 , according to the present application. The system 100 includes at least one device 102 and at least one peer-to-peer network 110 ,
  • The device 102 includes at least one output device 106 , The output device 106 is at least for outputting, in particular sending out, data records via a communication data network 108 set up. The communication data network 108 may be a wireless and / or wired communication data network 108 be. Preferably, the output device 106 a transmitting / receiving device 106 be configured and in particular for sending and receiving records, for example in the form of record messages.
  • In addition, the device includes 102 at least one PUF device 104 , The PUF facility 104 can in particular by anyway in the device 102 implemented electronic components, circuits, etc. may be formed. The PUF facility 104 In the present case, it is distinguished by the fact that a (specific) key (in the form of a bit sequence), also called a response, depends on an input signal (in the form of a bit sequence), also called a challenge, and depending on the physical properties of the PUF Device, so the electronic components, circuits, is generated. Since the physical properties are inherent in the manufacturing process and are uniquely associated with the manufactured device, a corresponding PUF key can be uniquely associated with the device 102 be assigned.
  • By a challenge signal, for example, the electronic components, circuits, etc. are configured accordingly. By means of a (not shown) measuring mechanism, the state caused by the configuration of the electronic components, circuits, etc. of the PUF device 104 measured and provided as a response or key (in the form of a bit string).
  • This at least one PUF key is issued when issuing a record from the output device 106 used. By this is meant, in particular, that the data record is provided with the PUF key in such a way that the authenticity or authenticity of the data contained in the data record or data record message is thereby occupied.
  • The devices may be preferred 104 and 106 be enclosed by a (not shown) housing and / or a (not shown) suitable encapsulation in order to further increase the security against manipulation.
  • An essential difference to a prior art system is that in the system 100 no central authority is provided. In the present case, the system points 100 at least one peer-to-peer network 110 or a computer-computer network 110 on. The peer-to-peer network 100 includes a variety of peer computers 112.1 to 112.3 (also called node or computer). It is understood that more than the illustrated three peer computer 112.1 to 112.3 can be provided. A peer-to-peer network 122 In the present case, it is distinguished by the fact that preferably each node and / or subscriber is connected to every other node and / or subscriber. This can be done over a wireless or wired network. For example, the Internet can be used. This network may be at least partially identical to the communication data network 108 be.
  • In addition, the peer computers 112.1 to 112.3 as equal peer computers 112.1 to 112.3 configured to be different from a traditional server-client structure.
  • The illustrated three peer computers 112.1 to 112.3 include (each) a peer-to-peer application 114 , As you can see, this is on every peer computer 112.1 to 112.3 the same peer-to-peer application 114 implemented. Preferably, the peer-to-peer application 114 one of all participants in particular (not just the peer computer 112.1 to 112.3 ) of the peer-to-peer network 110 accessible public register 114 be. Every peer computer 112.1 to 112.3 preferably has the (entire) public register 114 on. It can also be provided that only a part of the register is provided on a peer. In a particularly preferred embodiment, the peer-to-peer application 114 a blockchain 114 be.
  • Furthermore, in the 1 implied that one of the device 102 issued record from the peer-to-peer network 110 or the peer-to-peer application 114 can be received. For example, the system can 100 comprise a peer-to-peer module (not shown) which, for example, stores the keyed record from the device 102 and in particular to the peer-to-peer network 110 or the peer-to-peer application 114 at least can pass on.
  • In the present case, by means of the peer-to-peer application 124 a data exchange operation of at least part (> 1) of the peer computers 112.1 to 112.3 , preferably from all peer computers 112.1 to 112.3 , be monitored. The peer-to-peer application 114 has for this purpose in the present embodiment, an authenticity module 116 and a key register 118 on.
  • The key register 118 is at least on the three illustrated peer computers 112.1 to 112.3 implemented. In the key register 118 are at least the keys of the system 100 registered devices 102 saved. For example, for each registered device 102 at least one challenge-response pair of the registered device 102 be saved. It is understood that in the key register 118 further data of the device 102 how device type (sensor, actuator and / or processing device), installation location, task, manufacturer, last maintenance, reputation factor, communication address, etc., can be stored.
  • The authenticity module 116 is set up here to check the authenticity of a data record. The application according to the system 100 in this case, in particular, allows a verification of the authenticity of the data contained in the data record. In other words, with the authenticity module 116 be checked whether the record and / or the data contained therein could be manipulated.
  • To verify the authenticity is the authenticity module 116 to verify the key used in the output of the record based on the key register 118 , in particular that in the key register 118 stored keys, set up. Preferably, the execution of the authenticity module 116 automatically after receiving a record through the peer-to-peer application 114 to be started. In particular, the execution of the authenticity module 116 on at least part of the peer computer 112.1 to 112.3 , that is, a plurality of peer computers 112.1 to 112.3 , at least started almost parallel. In particular, each authenticity module 116 Check the key used in the output of the record by, in particular, evaluating whether this key belongs to one of the key registers 118 stored key corresponds. Only if every authenticity module 116 of the part of the peer computer 112.1 to 112.3 reaches a positive authenticity result, that is, a correspondence described above, the record is rated as authentic or real. In this case, the data record can then be stored, further processed and / or forwarded. Otherwise, further processing is blocked and the record is marked as not sufficiently authentic, for example. Further measures may follow.
  • The 2 shows a schematic view of another embodiment of a system 200 according to the present application. In order to avoid repetition, essentially only the differences from the exemplary embodiment will follow 1 described. For the other components of the system 200 Reference is made in particular to the above statements.
  • The system 200 is present at least partially in a vehicle 250 , especially a car 250 , in particular, the system can 200 at least partially the electrical system 252 of the vehicle 250 form. In particular, the devices according to the application 202.1 . 202.2 . 202.3 of the system 200 Part of the electrical system 252 (or more vehicle electrical systems).
  • A first exemplary device 202.1 may be a sensor device 202.1 with a sensor device 222 , in particular a sensor 222 , be. For example, the device 202.1 a speedometer 202.1 be. It is understood that the following remarks on a speedometer 202.1 in a simple way to other sensor devices of the vehicle 250 can be transmitted.
  • The speedometer 202.1 can the speed of the vehicle 250 to capture. These captured parameter values may be in the form of data records or messages by an output device 206.1 be issued. The present is in the output device 206.1 a (previously described) PUF device 204 and in particular a signing device 232 integrated. The signing device 232 is set up, in particular to sign every issued record. To do this, the PUF key is used by the PUF facility 204 the signing device 232 (eg message authentication device) provided.
  • The data record can in this case via an internal communication network 208.1 to a processing device 202.3 , For example, a motor controller 202.3 (ECU). It is understood that the following remarks on a motor control 202.3 in a simple way to other processing devices of the vehicle 250 can be transmitted.
  • Furthermore, an example of an actuator device 202.2 shown. The actuator device 202.2 has an actuator device 224 on to an actuatable element 226 according to a provided command data set and / or signal. The command signal and / or command data set can, for example, via the internal communication network 208.1 be received. For example, a transmitting / receiving device 236 the engine control 202.3 send out a corresponding command data record. This command data set can also be implemented by means of a PUF device 204 be provided with a key.
  • Also, the actuator device 202.2 Data records, such as status data records, in particular to the engine control 202.3 output. For this purpose, the actuator device 202.2 an output device 206.2 , a PUF facility 204 and by way of example an encryption device 230 on. The encryption device 230 is for encrypting the output record using the device 202.2 uniquely assigned PUF key. It is understood that, alternatively or additionally, a previously described marking device 232 can be provided. encryptor 230 and PUF facility 204 are preferably in the output device 206.2 integrated. In this case, the output device 206.2 in particular be a transmitting / receiving device.
  • The engine control 202.3 can have another output device 206 feature. The further output device 206 the engine control 202.3 especially as a peer-to-peer module 240 with a PUF facility 204 be formed. The peer-to-peer module 240 is the engine control 202.3 assigned. In particular, in the present embodiment, the peer-to-peer module 240 in the engine control 202.3 integrated.
  • A peer-to-peer module 240 is in the present case set up, at least with the peer-to-peer network 210 that is, the majority of peer computers 212.1 . 212.2 (In the present case only two are shown in favor of a better overview) of the peer-to-peer network 210 , to communicate. In other words, it is a peer-to-peer module 240 or to this peer-to-peer module 240 corresponding device 202.3 at least participants in the peer-to-peer network 210 , Here are each participant of the peer-to-peer network 210 preferably all participants of the peer-to-peer network 210 known.
  • For example, the peer-to-peer module 240 one from the speedometer 202.1 received sensor data set to the peer-to-peer application 214 send. The sensor dataset is with the PUF key of the speedometer 202.1 Mistake. In the present case, the sensor data set is especially appropriately signed. This sensor dataset includes the PUF key of the speedometer 202.1 is from the peer-to-peer module 240 the engine control 202.3 in the form of another record, in addition to the PUF key of the engine control 202.3 is sent to the peer-to-peer application 214.
  • In a preferred embodiment (not shown), the peer-to-peer module 240 may include a communication device to a vehicle-internal or vehicle-external peer-to-peer application 214 set up. Examples are ECU of vehicle control, ECU of engine control, ECU of the entertainment system, Telematics device, eCall device or OBD device, u, a ..
  • It should be noted that the engine control 202.3 via a processing device 234 (Eg processor, microcontroller, etc.) has to process received data and output, for example, according to the previous versions. For example, the sensor data can be processed to generate a command data set.
  • As can also be seen, in the present case there is a data storage arrangement 242 intended. Preferably, the data storage arrangement 242 containing a plurality of decentralized (not shown) Storage units, a distributed database system (such as IPFS) or a distributed object store (such as storj), or a distributed distributed database (such as BigchainDB) that is from the peer-to-peer application 214 , in particular by a control module 217 , controlled and / or managed. The control module 217 In particular, it may be used to control and / or control access to the data storage device 242 be furnished.
  • In particular, after receiving a record through the peer-to-peer application 214 the one or more keys of the record can be checked in the manner described above.
  • In a particular variant of a vehicle system according to the present application, at least part of the devices of the vehicle electrical system can form an internal peer-to-peer network. This internal peer-to-peer network can work with the external peer-to-peer network shown 210 be connected. For example, the engine control 202.3 both a peer computer of the internal peer-to-peer network and the external peer-to-peer network 210 be.
  • The 3 shows a schematic view of another embodiment of a system 300 according to the present application. In order to avoid repetition, essentially only the differences from the exemplary embodiments follow 1 and 2 described. For the other components of the system 300 Reference is made in particular to the above statements. In addition, the peer-to-peer network with only one peer computer was in favor of a better overview 312 shown. It is understood that a plurality of peer computers may be provided.
  • In the present embodiment, the system 300 at least partially in a building 354 integrated. In particular, the system can 300 at least partially through the devices 302.1 . 302.2 . 302.3 a home automation network 356 be formed.
  • The exemplified devices 302.1 . 302.2 . 302.3 In particular, they include a sensor device 302.1 , For example, a temperature sensor for detecting a room temperature, an actuator device 302.2 For example, set up for the operation of a valve 326 a heating system, and a processing device 302.3 For example, a home automation controller 302.3 ,
  • In the manner described above (see in particular 2 ) records can be output and / or received. Furthermore, in particular after receipt of a data record by the peer-to-peer application 314 the one or more keys of the record are checked in the manner described above.
  • Moreover, in the present embodiment, the system includes 300 one through the peer-to-peer application 314 controlled off-chip computing device 358 , Such an off-chip computing device 358 can be a calculation module 360 to perform algorithms, cognitive analytics, machine learning and / or artificial intelligence (AI), for example, the home automation network replacement process and / or processes 356 to optimize.
  • Also, an authentication device (e.g., handset) (not shown) may be provided with another authenticity module and another key register to handle the checking of issued records in the event of a network error. Such a device may be connected to the peer-to-peer network. Required CPRs or bit rings can then be automatically synchronized to this authentication device in the on-line case. This synchronization can be controlled via a registry on the peer-to-peer application.
  • 4 shows a schematic view of an embodiment of a peer-to-peer application 414 according to the present application. The peer-to-peer application 414 is in particular a viewable or readable for the participants of a peer-to-peer network registers in which messages / records of devices or participants of the peer-to-peer network can be written and / or read from the news / records , In a preferred embodiment, the peer-to-peer application 414 a blockchain 414 be.
  • Hereinafter, in the detailed description of the present embodiment, it is assumed that the peer-to-peer application 414 by a blockchain 414 is. However, the following explanations can be easily transferred to other peer-to-peer applications.
  • The blockchain 414 will be out of at least one block 451 to 455 , preferably a plurality of blocks linked together 451 to 455 , educated. The first block 451 can also be Genesis block 451 to be named. As can be seen, a block refers 453 . 455 (except the first block 451 ) to the previous block 451 . 453 , One new block can be created by a computationally intensive process (for example, so-called "mining" or by a corresponding process) and in particular be provided to all participants of the peer-to-peer network.
  • The present blockchain 414 is in particular adapted to receive messages or data records from a peer-to-peer module of a subscriber of the peer-to-peer network, such as a peer-to-peer module of a device described above, and this message or this data record in the blockchain 414 save. In particular, a new message may be in the current block 455 the blockchain 414 saved and published. Due to the design of a blockchain 414 as a public register 414 , the message of a peer-to-peer module of preferably all participants of the peer-to-peer network can be read and thus checked in particular.
  • In the present blockchain 414 may be different types of messages or records, for example, within a smart contract (algorithm and / or memory on the blockchain) (and / or outside the blockchain 414 ), processed and / or stored. As already described, the blockchain 414 an authenticity module 416 include. The authenticity module 416 is in particular a software module in the form of a smart contract that can be executed by the respective computer peer. The execution can be started in particular after receipt of a data record and carried out in accordance with the above statements. Alternatively, such a module can also be set up in a trusted execution environment, which can be connected to the peer-to-peer application via a peer-to-peer module and, in particular, can be controlled by it.
  • In addition to an authenticity module 416 can the blockchain 414 a key register 418 (also called CPR register) and / or a control module 417 for controlling access to a key register provided by an off-chip data storage device, as described above.
  • In addition, in the present case is a register module 460 intended. The register module 460 is for registering a device in the key register 418 at least by storing the key uniquely assigned to the device (and / or several CPRs). A registration process may comprise performing a communication test as well as checking further, specifiable registration rules.
  • A registration process can also cause the creation of (decentralized) Digital Product Memory. Additionally, in the registration process, individual components may be associated with an associated system (e.g., car, building, network) (e.g., registering the components in a configuration tree). Thus, the identity of individual devices e.g. be assigned to the identity of a vehicle.
  • Furthermore, a peer-to-peer application 414 basically be configured to generate record replacement operation agreement modules (not shown). For example, in a record replacement transaction agreement module, it may be determined which conditions are to be fulfilled for a permissible data record exchange and between which entities (for example, a user's vehicle, insurance provider) an exchange can take place. For this purpose, the entities, for example a peer-to-peer module of an entity, can initiate the generation of a record interchange agreement module. Subsequently, the replacement process can be carried out based on the data elements generated and stored in the record interchange agreement module. In particular, the generation can be done by sending at least one request message to the peer-to-peer application 414 be initiated.
  • A request message may include, for example, identifier (s) of the entity (s) involved, at least one exchange criterion that must be fulfilled or complied with during or after the replacement process, and / or information about the data content. It is understood that a request message may have fewer data elements or more data elements.
  • Furthermore, at least one exchange criterion, preferably several exchange criteria, can be specified. For example, a transaction criterion can be specified as exchange criterion. This may be a criterion that must be met by an entity to generate a record replacement operation agreement module. For example, the transaction criterion may specify a token amount (which may correspond to a certain monetary value) that must pay another entity to receive the data.
  • It is understood that other exchange criteria may be established. Further details can be, for example, a time stamp, an identifier of the message and further transaction criteria, such as an indication of the desired data type, etc.
  • Another message may be an acceptance message. The acceptance message can be generated by another peer-to-peer module of the further entity and in particular to the peer-to-peer application 414 be transmitted. This can be done in particular after reading the request message.
  • An acceptance message may have the same or at least similar data elements as an associated request message. In addition, the acceptance message may include, for example, a reference to a previous request, such as the identifier of the request message.
  • Also, query messages and / or accept messages may be exchanged directly between the entities. Preferably via a peer-to-peer communication protocol.
  • In the exchange criterion, a lower / higher transaction criterion can be specified in an acceptance message. If an acceptance message includes a lower / higher / different transaction criterion or the like, the acceptance message may be referred to as a counter offer message. This can be accepted by the first entity by a further acceptance message. Based on this, at least one peer-to-peer module may cause the generation of a record replacement operation agreement module by the peer-to-peer application.
  • In particular, there may be multiple request messages and / or acceptance messages. Each entity can specify preferences by which to generate at least one record interchange agreement module. In a preferably automatic, for example iterative, process, each request message can preferably be assigned an acceptance message which corresponds as optimally as possible.
  • A record replacement process agreement module (not shown) may be stored within a smart contract in a block.
  • A smart contract may in this case comprise computer program code (short code). In particular, the exchange of data records between the at least two entities can be agreed in the record exchange transaction agreement module.
  • In particular, the peer-to-peer application 414 adapted to store the stored records / messages in a tamper-proof manner. This is essentially achieved by the fact that the whole peer-to-peer network, for example, a data set exchange agreement module can be verified by the cumulative computing power of the entire peer-to-peer network.
  • Preferably, at least the previously described messages / records in a block 453 . 455 the blockchain 424 be hashed in pairs by a Merkle tree. In particular, only the last hash value, the so-called root hash, can be noted as a checksum in the header of a block. Then the block can be concatenated with the previous block. Chaining the blocks can be done using this root hash. Each block may include the hash of the entire previous block header in the header. This allows the order of the blocks to be clearly defined. In addition, the subsequent modification of previous blocks or of the messages stored in the previous blocks can also be (practically) excluded as, in particular, the hashes of all subsequent blocks must also be recalculated in a short time.
  • It is understood that the aforementioned modules / data sets, etc. can be at least partially combined with each other. It is also understood that at least in part the data can be stored in a previously described data storage arrangement.
  • Also, instead of a linear blockchain, a DAG tangle or a blockchain database or a Lightning or State Channel network or blockchain integration technology, such as Interledger Protocol or a combination of said peer-to-peer technologies, may be used.
  • 5 shows a schematic view of another embodiment of a system 500 according to the present application. In order to avoid repetition, essentially only the differences from the exemplary embodiments follow 1 . 2 and 3 described.
  • The highly simplified system 500 in the present case comprises seven entities 502.1 . 502.2 . 512.1 . 512.2 in particular comprising and / or forming peer computers of a peer-to-peer network 510. Each peer computer may have a peer-to-peer application (not shown), eg the blockchain 414 according to 4 , provide or include.
  • In the present case, peer computers are devices 502.1 . 502.2 , For example, sensor devices, and by computing devices 512.1 . 512.2 educated.
  • Furthermore, two different types of peer computers or node computers are present in particular 502.1 . 512.1 respectively. 502.2 . 512.2 shown. All peer computers 502.1 to 512.2 are from the peer-to-peer network 510 includes. In the present embodiment, however, only a part of the peer computers checks 502.1 to 512.2 , in this case, the peer computers 502.1 . 512.1 the validity of a received record based on the at least one key used and the stored permissible keys. In particular, only a part of the peer computer 502.1 . 512.1 configured to execute the authenticity module (not shown).
  • It can also be provided that only a part of the peer computer stores the entire peer-to-peer application and / or only a part of the peer computer executes the algorithms of the (further) smart contracts. Since the validation / verification can be associated with a considerable amount of computation, it may be advantageous for reasons of efficiency, if only a part of the peer computer 502.1 . 512.1 , especially high-performance peer computers 502.1 . 512.1 , the validation or verification of the records make. Powerful means in particular a high computing power. In other words, in the present case, a valid data record is assumed in the peer-to-peer application, such as a blockchain, if (only) part of the peer computer 502.1 . 512.1 has come to a positive result of a verification process. It goes without saying that even a single, especially high-performance peer can perform the validation. In this case, the other peer computers may be implemented as observation computers arranged to confirm at least the correctness of the verification process.
  • Likewise, in an alternative embodiment (not shown) it can be provided that a particularly large peer-to-peer network can be divided into two or more clusters. For example, with a peer-to-peer network, validation can only be performed by the members of a cluster.
  • Furthermore, it can be provided in an embodiment (not shown) that a control device of the provider, user of fleet operators, vehicle manufacturers, building managers or the network operator or central control systems for exchange module infrastructures are connected to the peer-to-peer network.
  • The 6 shows a diagram of an embodiment of a method according to the present application. In a first step 601 can, for example, according to the previous versions (see, eg 2 . 3 and / or 4), a previously generated record is provided with a PUF key. For this purpose, the PUF device can generate the PUF key depending on a challenge. For example, the record can be signed with the PUF key. This record will then be in step 601 issued, in particular by an output device of the device to which the PUF key is uniquely assigned, sent out.
  • Prior to initial output of a record, a registration step (not shown) may be performed to register the device in the system of the present invention.
  • In step 602 Provide Peer-to-Peer Peer-to-Peer Peer-to-Peer In Step 603 a key register controllable at least by the peer-to-peer application is provided, at least for storing the key uniquely assigned to the device.
  • Then, especially after a record is received by the peer-to-peer application, this record is checked, in particular the record that is output and received by the peer-to-peer application is executed by executing at least one authenticity module by at least one part of the peer. Computer of the peer-to-peer network. In particular, the checking includes evaluating the key used in the output of the record based on the key register (as previously described).

Claims (11)

  1. System (100, 200, 300, 500), comprising: - at least one device (102, 202, 302) having at least one output device (106, 206, 306) configured to output at least one data record, and having at least one PUF Means (104, 204, 304) arranged to generate at least one key uniquely assigned to the device (102, 202, 302), the key being used when issuing the data record, at least one peer-to-peer network (110 , 210, 310, 510) comprising at least one peer-to-peer application (114, 214, 314, 414), and - at least one of the peer-to-peer application (114, 214, 314, 414) at least one controlled key register (118, 218, 318, 418) arranged at least for storing the key uniquely assigned to the device (102, 202, 302), the peer-to-peer application (114, 214, 314, 414) at least one of at least part of the peer computers (112, 212, 312, 502, 512, 564) of the peer-to-peer network (110, 210, 310, 510) executable authenticity module (116, 216, 316, 416), and - wherein the authenticity module (116, 216, 316, 416) for verifying the key used in the output of the record based on the key register (118, 218, 318, 418) upon receipt of the record by the peer-to-peer application (114, 214, 314, 414).
  2. System (100, 200, 300, 500) after Claim 1 , characterized in that the device (102, 202, 302) is formed as: - Sensor device (202.1, 302.1) with at least one sensor device (222, 322), adapted for detecting at least one parameter, the output data set in particular at least the detected parameter value, and / or - Aktorvorrichtung (202.2, 302.2) with at least one actuator means (224, 324), adapted for moving an actuatable element (226, 326), wherein the output data set in particular at least one state of the actuator means (224, 324 ) and / or the actuatable element (226, 326), and / or - processing device (202.3, 302.3) with at least one processing device (234, 334), arranged for processing receivable data, the output data set, in particular, at least the processed data includes.
  3. System (100, 200, 300, 500) after Claim 1 or 2 , characterized in that - the system (100, 200, 300, 500) comprises at least one peer-to-peer module (240, 340), - wherein the peer-to-peer module (240, 340) at least for Transmitting the record used for the key to the peer-to-peer application (114, 214, 314, 414).
  4. System (100, 200, 300, 500) according to one of the preceding claims, characterized in that - the device (102, 202, 302) comprises at least one signing device (232), - wherein the signing device (232) for signing the output data set is set up using the key uniquely assigned to the device (102, 202, 302).
  5. System (100, 200, 300, 500) according to one of the preceding claims, characterized in that - the device (102, 202, 302) comprises at least one encryption device (230), - wherein the encryption device (230) for encrypting the output data set is set up using the key uniquely assigned to the device (102, 202, 302).
  6. System (100, 200, 300, 500) according to one of the preceding claims, characterized in that - the peer-to-peer application (114, 214, 314, 414) comprises at least one register module (460), - wherein the register module (460) for registering a device (102, 202, 302) in the key register (118, 218, 318, 418) at least by storing the key uniquely associated with the device (102, 202, 302).
  7. System (100, 200, 300, 500) according to one of the preceding claims, characterized in that - the system (100, 200, 300, 500) is at least partially integrated in a vehicle (350), or - the system (100, 200, 300, 500) is at least partially integrated in a home automation system (354).
  8. System (100, 200, 300, 500) according to one of the preceding claims, characterized in that - the peer-to-peer application (114, 214, 314, 444) is a decentralized register or a distributed database, and - the peer to-peer application (114, 214, 314, 414), in particular a blockchain or a decentralized ledger.
  9. A method, comprising: outputting at least one data record by an output device (106, 206, 306) of a device (102, 202, 302) using at least one key assigned to the device (102, 202, 302), the key being transmitted through at least one PUF device (104, 204, 304) integrated in the device (102, 202, 302) is generated, providing a peer-to-peer application (114, 214, 314, 414) of a peer-to-peer application Peer network (110, 210, 310, 510), providing a key register (118, 218, 318, 418) controlled at least by the peer-to-peer application (114, 214, 314, 414), at least for Save the Device (102, 202, 302) uniquely assigned key, and - checking the issued and by the peer-to-peer application (114, 214, 314, 414) received record by executing at least one authenticity module (116, 216, 316, 416) through at least a portion of the peer computers (112, 212, 312, 502, 512, 544) of the peer-to-peer network (110, 210, 310, 510), wherein the checking comprises evaluating the output of the peer-to-peer network Record key used based on the key register (118, 218, 318, 418).
  10. Device (102, 202, 302) comprising: at least one output device (106, 206, 306) arranged to output at least one data set, at least one PUF device (104, 204, 304) configured to generate at least one key uniquely assigned to the device (102, 202, 302), the key being used when outputting the record, - wherein the output device (106, 206, 306) is formed by a peer-to-peer module (240, 340), arranged at least for transmitting the data set used the key to a peer-to-peer application (114, 214 , 314, 414) of a peer-to-peer network (110, 210, 310, 410) such that at least one of at least a portion of the peer computers (112, 212, 312, 502, 512, 564) of the peer computer Peer-to-peer network (110, 210, 310, 410) executable authenticity module (116, 216, 316, 416) of the peer-to-peer application (114, 214, 314, 414) at the output of the record used key based on a key-storing key register (118, 218, 318, 418) checked.
  11. A peer-to-peer application (114, 214, 314, 414) for a peer-to-peer network (110, 210, 310, 510), comprising: at least one authenticity module (116, 216, 316) executable by at least part of the peer computers (112, 212, 312, 502, 512, 564) of the peer-to-peer network (110, 210, 310, 510) 416) arranged to check a key received by the peer-to-peer application (114, 214, 314, 414) and by using a key generated by a PUF device (104, 204, 304) by a device (102, 202, 302) output record, - wherein the checking comprises evaluating at least the key used in the output of the record based on a key register (118, 218, 318, 418) at least controlled by the peer-to-peer application (114, 214, 314, 414) for storing the key uniquely associated with the device (102, 202, 302).
DE102017122227.8A 2017-09-26 2017-09-26 System, especially authenticity system Pending DE102017122227A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE102017122227.8A DE102017122227A1 (en) 2017-09-26 2017-09-26 System, especially authenticity system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102017122227.8A DE102017122227A1 (en) 2017-09-26 2017-09-26 System, especially authenticity system
PCT/EP2018/073966 WO2019063256A1 (en) 2017-09-26 2018-09-06 System, in particular authenticity system

Publications (1)

Publication Number Publication Date
DE102017122227A1 true DE102017122227A1 (en) 2019-03-28

Family

ID=63528771

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102017122227.8A Pending DE102017122227A1 (en) 2017-09-26 2017-09-26 System, especially authenticity system

Country Status (2)

Country Link
DE (1) DE102017122227A1 (en)
WO (1) WO2019063256A1 (en)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140331302A1 (en) * 2011-12-14 2014-11-06 Gemalto Sa Method for securing an electronic document
US20170142123A1 (en) * 2015-11-13 2017-05-18 Kabushiki Kaisha Toshiba Data distribution apparatus, communication system, moving object, and data distribution method

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9716595B1 (en) * 2010-04-30 2017-07-25 T-Central, Inc. System and method for internet of things (IOT) security and management
JP2018515048A (en) * 2015-04-06 2018-06-07 ビットマーク,インコーポレイテッドBitmark, Inc. System and method for decentralized title recording and authentication

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140331302A1 (en) * 2011-12-14 2014-11-06 Gemalto Sa Method for securing an electronic document
US20170142123A1 (en) * 2015-11-13 2017-05-18 Kabushiki Kaisha Toshiba Data distribution apparatus, communication system, moving object, and data distribution method

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ADEPT: An IoT Practitioner Perspective, Draft Copy for Advance Review, IBM 2015, URL: http://static1.squarespace.com/static/55f73743e4b051cfcc0b02cf/55f73e5ee4b09b2bff5b2eca/55f73e72e4b09b2bff5b3267/1442266738638/IBM-ADEPT-Practictioner-Perspective-Pre-Publication-Draft-7-Jan-2015.pdf?format=original [abgerufen im Internet am 04.07.2018] *
ZYSKIND, G. [et al.]: Decentralizing Privacy: Using Blockchain to Protect Personal Data, 2015 IEEE Security and Privacy Workshops Year: 2015, Pages: 180 – 184, URL: https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=7163223 [abgerufen im Internet am 04.07.2018] *

Also Published As

Publication number Publication date
WO2019063256A1 (en) 2019-04-04

Similar Documents

Publication Publication Date Title
He et al. An efficient identity-based conditional privacy-preserving authentication scheme for vehicular ad hoc networks
EP1708406A2 (en) Method and apparatus for distributing new keys in a secure group of collaborators
EP3346639A1 (en) Certify and split system and method for replacing cryptographic keys
ES2672340T3 (en) System and method to ensure machine-to-machine communications
Liu et al. Shared authority based privacy-preserving authentication protocol in cloud computing
DE112013002752T5 (en) System and method for verification of messages in broadcast and multicast networks
US7620824B2 (en) Data communicating apparatus, data communicating method, and program
JP2013516685A (en) System and method for enforcing computer policy
Boudguiga et al. Towards better availability and accountability for iot updates by means of a blockchain
Ambrosin et al. SANA: secure and scalable aggregate network attestation
US7266705B2 (en) Secure transmission of data within a distributed computer system
Ray et al. Secure logging as a service—delegating log management to the cloud
CN102461060B (en) Key management in secure network enclaves
CN103931220B (en) For the cipher key derivation function of network communication
Puthal et al. A dynamic prime number based efficient security mechanism for big sensing data streams
Aman et al. Mutual authentication in IoT systems using physical unclonable functions
US9628276B2 (en) Discovery of secure network enclaves
Liang et al. Towards data assurance and resilience in iot using blockchain
Esposito et al. On security in publish/subscribe services: A survey
US9043598B2 (en) Systems and methods for providing secure multicast intra-cluster communication
US9197422B2 (en) System and method for differential encryption
US9832026B2 (en) System and method from Internet of Things (IoT) security and management
CA2780643C (en) Cryptographically secure authentication device, system and method
US9215228B1 (en) Authentication of devices having unequal capabilities
US9716595B1 (en) System and method for internet of things (IOT) security and management

Legal Events

Date Code Title Description
R083 Amendment of/additions to inventor(s)
R082 Change of representative

Representative=s name: COHAUSZ & FLORACK PATENT- UND RECHTSANWAELTE P, DE

R163 Identified publications notified