Verification of authenticity of data source

Abstract

A method for verifying the authenticity of a data source is described herein. The method includes generating a key and receiving a digital certificate. The key may be a private key of a key pair, and the digital certificate may be a qualified electronic signature (QES) certificate that is bound to the data source and generated by an electronic identification, authentication and trust service (eIDAS). And creating a signature certificate by using the digital certificate and the secret key. The signed certificate may be stored in a secure element of a recording device. The recording device receives a data stream that may include one or more of audio, video, photo, or other sensor data. And signing the data stream by using the signature certificate. A public key of the key pair may then be used to verify that the data stream is initiated at the data source.

Description

Technical Field

[0001] The present disclosure generally relates to authentication and, more particularly, to verifying the authenticity of data sources. Background Art

[0002] Today's digital media landscape is more vulnerable to misinformation than ever, and this problem will only accelerate in the future with the continued advancement of artificial intelligence (AI) tools for audio and video processing. For example, the development of media editing tools such as Photoshop and the GNU Image Manipulation Program (GIMP) has made it possible to create fake photographic evidence. Other software provides the ability to perform similar manipulations on audio recordings. However, creating fake but plausible photographic evidence still requires a significant amount of work by a professional if such photo editors are used. Using machine learning (ML), software can be created that can generate realistic images and accurate vocal syntheses without a significant amount of input from an operator.

[0003] The result of using media editing tools is that it is more difficult to distinguish between trustworthy and malicious media sources. An important aspect of this challenge is the ability to verify the authenticity of data sources as media cloning becomes more sophisticated. Summary of the Invention

[0004] According to a first aspect of the present invention, there is provided a method comprising:

[0005] Generating a key;

[0006] Receiving a digital certificate;

[0007] Creating a signature certificate using the digital certificate and the key;

[0008] Storing the signature certificate in a secure element of a recording device; and

[0009] Receiving a data stream by the recording device and signing the data stream with the signature certificate.

[0010] In one or more embodiments, the digital certificate is a qualified electronic signature (QES) certificate provided by an eSign application of an electronic identification, authentication, and trust service (eIDAS) token.

[0011] In one or more embodiments, creating the signature certificate according to the QES certificate and the key includes signing the key with the QES certificate in a provisioning device.

[0012] In one or more embodiments, the method further comprises:

[0013] Generating a hash of the signature certificate by the provisioning device;

[0014] The digest of the signature certificate is transmitted to the eIDAS token by the dispensing device;

[0015] The eIDAS token signs the digest of the signature certificate to create a signed signature certificate;

[0016] The signed signature certificate is stored in the secure element of the dispensing device;

[0017] The signed signature certificate is transferred from the dispensing device to the recording device; and

[0018] The recording device uses the signed signature certificate to sign the data stream.

[0019] In one or more embodiments, the eIDAS token includes an NFC interface for communicating with an NFC interface of the dispensing device.

[0020] In one or more embodiments, the key is a private key of an asymmetric key pair.

[0021] In one or more embodiments, the method further includes verifying the authenticity of the data stream using the public key of the asymmetric key pair.

[0022] In one or more embodiments, the recording device performs the verification of the authenticity of the data stream.

[0023] In one or more embodiments, the data stream includes one or more of audio, photo, and video information.

[0024] In one or more embodiments, the dispensing device is a smart phone, and the recording device is one of a camera, headphones, a video recorder, or a diagnostic device.

[0025] According to a second aspect of the present invention, there is provided a method for verifying the authenticity of a data source, the method comprising:

[0026] Generating a key pair;

[0027] Receiving a digital certificate;

[0028] Combining the private key of the key pair with the digital certificate to create a signature certificate;

[0029] Generating a digest of the signature certificate;

[0030] Signing the digest of the signature certificate by a certificate authority;

[0031] Storing the signed and digested signature certificate in a secure element of a recording device;

[0032] Receiving, by the recording device, a data stream from the data source and signing the data stream with the signed and hashed signature certificate; and

[0033] Verifying the authenticity of the data stream using the public key of the asymmetric key pair.

[0034] In one or more embodiments, the recording device is one of a camera, a headset, a video recorder, or a diagnostic device.

[0035] In one or more embodiments, the data stream includes one or more of audio, photo, and video information.

[0036] In one or more embodiments, the signed and hashed signature certificate is transmitted from a dispensing device to the recording device via a Near Field Communication (NFC) interface.

[0037] In one or more embodiments, the dispensing device is a smart phone.

[0038] In one or more embodiments, the method further includes storing the signed and hashed signature certificate in a trusted execution environment of the dispensing device.

[0039] In one or more embodiments, the signed and hashed signature certificate is stored as metadata of the data stream.

[0040] In one or more embodiments, the signed and hashed signature certificate is stored separately from the data stream.

[0041] In one or more embodiments, the digital certificate is a Qualified Electronic Signature (QES) certificate.

[0042] In one or more embodiments, the certificate authority is an Electronic Identification, Authentication and Trust Services (eIDAS) token.

[0043] These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] The present invention is illustrated by way of example and is not limited by the accompanying drawings, in which like reference numerals indicate like elements. For simplicity and clarity, the elements in the figures are shown and these elements are not necessarily drawn to scale.

[0045] Figure 1 A system for creating a signature certificate for signing a data stream according to one embodiment is shown.

[0046] Figure 2Shows a smartphone according to an embodiment, the smartphone communicating with an eIDAS token to sign a signature certificate in the smartphone.

[0047] Figure 3 Shows that according to an embodiment, a smartphone will Figure 2 transfer the signed signature certificate to a device.

[0048] Figure 4 Shows a method for capturing a data stream according to an embodiment.

[0049] Figure 5 Shows a method for verifying a data stream according to an embodiment.

[0050] Figure 6 Shows a system-on-chip (SoC) according to an embodiment. Detailed Description

[0051] Generally, a method for creating a signature certificate is provided, the signature certificate can be used to sign a data stream to allow verification of the authenticity of the data stream. In one embodiment, a signature certificate is created using a digital certificate and a key, and then the signature certificate is stored in a secure element of a recording device for capturing the data stream. Additionally, the method can be used to link a natural person's digital identity (e.g., a digital identity issued by a state as part of a national identification (ID) card) to a digitized output data stream. In one embodiment, a person's digital identity can be linked to, for example, digital audio data such that consumers of this audio data can verify its authenticity via an encrypted signature method. For example, a digital certificate such as a qualified electronic signature (QES) certificate can be combined with an encryption key to create a signature certificate, which can then be used to sign the data stream. The data stream can include, for example, one or more of digitized audio, video, or photographic content. The signature certificate can be stored as metadata together with the data stream, or stored separately and used to identify the source of the data stream. The encryption key is controlled by the owner or initiator of the data stream.

[0052] According to one embodiment, a method is provided, the method comprising: generating a key; receiving a digital certificate; creating a signature certificate using the digital certificate and the key; storing the signature certificate in a secure element of a recording device; and receiving a data stream by the recording device and signing the data stream with the signature certificate. The digital certificate may be a qualified electronic signature (QES) certificate provided by an eSign application of an electronic identification, authentication and trust service (eIDAS) token. Creating the signature certificate according to the QES certificate and the key may additionally include signing the key with the QES certificate in a provisioning device. The method may additionally include: generating a hash of the signature certificate by the provisioning device; transmitting the hash of the signature certificate by the provisioning device to the eIDAS token; signing the hash of the signature certificate by the eIDAS token to create a signed signature certificate; storing the signed signature certificate in a secure element of the provisioning device; transmitting the signed signature certificate from the provisioning device to the recording device; and signing the data stream by the recording device using the signed signature certificate. The eIDAS token may include an NFC interface for communicating with an NFC interface of the provisioning device. The key is a private key of an asymmetric key pair. The method may additionally include using the public key of the asymmetric key pair to verify the authenticity of the data stream. The recording device may perform the verification of the authenticity of the data stream. The data stream may include one or more of audio, photo and video information. The provisioning device may be a smartphone, and the recording device may be one of a camera, a headset, a video recorder or a diagnostic device.

[0053] In another embodiment, a method for verifying the authenticity of a data source is provided. The method includes: generating a key pair; receiving a digital certificate; combining the private key of the key pair with the digital certificate to create a signed certificate; generating a hash of the signed certificate; signing the hash of the signed certificate by a certificate authority; storing the signed and hashed signed certificate in a secure element of a recording device; receiving, by the recording device, a data stream of the data source and signing the data stream with the signed and hashed signed certificate; and verifying the authenticity of the data stream using the public key of the asymmetric key pair. The recording device may be one of a camera, a headset, a video recorder, or a diagnostic device. The data stream may include one or more of audio, photo, and video information. The signed and hashed signed certificate may be transferred from a dispensing device to the recording device via a Near Field Communication (NFC) interface. The dispensing device may be a smart phone. The method may further include storing the signed and hashed signed certificate in a trusted execution environment of the dispensing device. The signed and hashed signed certificate may be stored as metadata of the data stream. The signed and hashed signed certificate may be stored separately from the data stream. The digital certificate may be a Qualified Electronic Signature (QES) certificate. The certificate authority may be an Electronic Identification, Authentication and Trust Services (eIDAS) token.

[0054] The European Union provides online authentication via a national identity card implemented according to an Electronic Identification, Authentication and Trust Services (eIDAS) token known as an eIDAS token. In one embodiment, the eIDAS token is used to sign a key pair, which is then used to sign data packets of a media stream such that they are bound to the speaker's eIDAS token. A signed certificate for signing the data packets is created. This signed certificate must be cryptographically bound to the speaker's eIDAS token. This newly created and legally signed signed certificate is securely stored in a secure element of the device. The signed signed certificate provides data integrity and protection against modification of the data stream (e.g., audio or video). In addition, hardware may be provided to allow continuous data signing of a series of packets.

[0055] The eIDAS token stores the embedded electronic signature application named eSign application. The eSign application stores the QES certificate when activated. Using the eIDAS token, an electronic signature can only be created when supported by a qualified certificate. These can only be issued by a Qualified Trust Service Provider (QTSP) which is supervised via the EU Trust List and recognized as a European Trusted Provider (Qualified Electronic Signature Provider). Thus, the eIDAS token acts as a certificate authority for signing the signature certificate which is then used to sign the data stream. The lifespan of the QES certificate of the eSign application is limited and must be renewed every few years. Thus, the QES certificate of the eSign application itself is not most suitable to be used as the entity directly signing the data. Thus, according to one embodiment, a trusted QES certificate is used to sign the certificate based on the generated asymmetric key pair. By doing so, a local Public Key Infrastructure (PKI) is created which cryptographically binds the newly created key pair to the trusted key chain of the QES certificate.

[0056] Note that the created signature certificate can be used to sign audio, video, digital photos and other digitalized data. The signature certificate does not have to be developed or customized for the type of information produced and does not have to be meaningful and entertaining for people such as videos, audio and photos. In addition to audio, video and photos, the signature certificate can also be applied to any type of sensor data in industrial or medical environments.

[0057] Figure 1Figure 10 shows a system 10 for creating a signature certificate for signing a data stream according to an embodiment. The system 10 includes a provisioning device 11 and a recording device 12. The provisioning device 11 is used to create and sign a signature certificate. A key pair 14 is created. The key pair 14 can be an asymmetric key pair including a private key and a public key. A QES certificate 15 is used to sign 16 the private key of the key pair 14 to create a QES-signed signature certificate 17. In another embodiment, a different certificate type can be used to sign the private key. Then, the signature certificate 17 can be used in the recording device 12 to sign the data stream 13 received by the recording device 12, thereby generating a signed data stream 19. In one embodiment, the provisioning device 11 can be a smart phone, and the process of creating and signing the signature certificate can be implemented in an application running on a smart phone having a trusted execution environment (TEE) and a near field communication (NFC) interface. The recording device 12 can be any device that records data from the real world (e.g., video, photo, audio). For example, the recording device can capture an analog signal, perform analog-to-digital conversion, and store a digitized version of the analog signal in a memory. The recording device 12 can include one or more integrated circuits (chips), and the one or more integrated circuits are responsible for several actions required for data capture. In the case of an image, the analog capture can be performed by a set of lenses and photosensitive elements, which helps to convert the light intensity and wavelength into digital form. Then, a microcontroller can convert the raw digital data into a special file format (e.g., jpeg) that can be written to the memory of the recording device 12.

[0058] Using the signed signature certificate has at least two advantages. For example, an eIDAS token is not required for the actual data signing process. In addition, even if the eIDAS token or its QES certificate has to be updated, the signed signature certificate can be retained and reused.

[0059] Figure 2A smartphone 23 according to an embodiment is shown, the smartphone 23 communicating with an eIDAS token 21 to sign a signature certificate in the smartphone. The smartphone 23 acts as a provisioning device. The eIDAS token 21 includes an eSign application 22 and an NFC circuit 29. In one embodiment, the eIDAS token 21 can be a smart card. The smartphone 23 includes a provisioning application 24, a TEE 25, and an NFC circuit 28. The TEE 25 has relatively better security than the rich execution environment (REE) (not shown). A key pair 26 and a signature certificate 27 with a QES certificate are stored within the TEE 25. The NFC circuits 28 and 29 are used to interface the provisioning application 24 running on the smartphone 23 with the eSign application 22 of the eIDAS token 21. Under the guidance of the provisioning application 24, a signature certificate 27 is created in the TEE 25 based on the generated asymmetric key pair 26, as described above with respect to Figure 1 as described. A hash value of the signature certificate is calculated in the TEE 25 and transmitted to the eIDAS token 21 via NFC. Then, this hash value is sent to the eSign application 22 of the eIDAS token 21, where a signature certificate is created using the internally stored and state-approved QES certificate. Then the signature certificate 27 with QES is sent back to the smartphone 23, where the signature certificate is stored in the memory of the TEE25. The provisioning application 24 receives the calculated signature certificate 27 in return for the hash value and appends the hash value to the end of the signature certificate 27 with QES.

[0060] Figure 3 A smartphone 23 according to an embodiment is shown Figure 2 The smartphone 23 passes the signed signature certificate 27 to a recording device 32. After the signed signature certificate 27 is created, the signed signature certificate 27 is passed to the recording device 32 via the NFC circuit 28. The recording device 32 receives the signed signature certificate 27 via the NFC circuits 28 and 38 and is securely stored in the memory of a security element 39. The security element 39 is provided not only for securely storing the signature certificate 27 but also includes hardware-based cryptography. In one embodiment, the security element 39 can be powered only by using the NFC field of the smartphone 23. Thus, a secure connection using secure messaging (SM) can be established between the smartphone provisioning application 24 and the security element 39 to securely store the signature certificate 27 in the security element 39. Once the certificate transfer is complete, the smartphone 23 is no longer needed and can be removed. Then, the signature certificate 27 is used to sign 40 a data stream 33 to create a signed data stream 41.

[0061] From the user's perspective, Figure 2 and Figure 3The process shown for creating the signed signature certificate 27 may include: starting the provisioning application 24 on the smartphone 23; positioning the eIDAS token 21 near the NFC interface 28 after requesting certificate signing; and keeping the NFC interface 38 of the recording device 32 close to the smartphone 23 until the certificate update of the signature certificate 27 in the security element 39 is completed. This description assumes that the eSign application 22 of the eIDAS token 21 is in an operational state and "activated". Then, if necessary, the public key of the key pair 26 can be used to verify that the data stream is a genuine data stream.

[0062] Figure 4 A method 50 for capturing a data stream according to an embodiment is shown. Method 50 begins at block 51. At block 51, an analog signal is captured by a recording device such as camera optics, a microphone, or other sensor data. At block 52, the analog data signal is converted into a raw digital data signal. This can be done using an analog-to-digital converter. At block 53, the raw data signal is processed into a specific file format. At block 54, the data file is saved in the memory of the recording device. Note that some blocks of the method may be mixed or run in parallel with other blocks. For example, processing the raw data into a specific file format (e.g., jpeg) may be interleaved with writing the file to the memory. The recording device may also create several files corresponding to the same photo. For example, in addition to the data saved in a specific file format such as jpeg, the raw data may also be saved. At block 55, the image file is processed using an encryption function to create a digital signature. At block 56, the digital signature is stored in the memory. Blocks 55 and 56 may be implemented as described above in Figures 1 - 3 or blocks 55 and 56 may be implemented in several different ways. For example, the encryption function may be a digital signature scheme based on public-key cryptography such as RSA (Rivest-Shamir-Adleman), or it may be a symmetric encryption scheme such as a hash-based message authentication code (HMAC). Note that in the case of public-key cryptography, the verification key can be published and thus anyone will be able to check whether the data stream comes from a given recording device. In the case of HMAC, only the recording device itself can confirm that the file was recorded by it. Depending on the application, both methods have advantages and disadvantages.

[0063] The storage of the digital signature can be done as a separate file, or the digital signature can be saved in the file along with the data stream as metadata. Note that in the case of a photo, there is only one signature for the photo, whereas in the case of a long data stream such as video or audio, a signature can be added to each frame, block or portion of the file (e.g., one signature per minute of recorded audio). Additionally, in order to verify that the data is from a specific data source, such as from a specific person using an ID token belonging to that person, the system can be used to verify that the data is from a specific recording device.

[0064] Figure 5 A method 60 for verifying that a digitized data stream is from a recording device according to one embodiment is shown. In one embodiment, as shown in block 61, a file to be verified is input into the recording device. At block 62, the recording device uses Figure 1 The verification is performed using a public key of a key pair created by a cryptographic circuit system of a processor (e.g., a system on a chip (SoC)) of the device. In one embodiment, the digital signature is stored in the image file as metadata or a watermark. If the digital signature is stored in a separate file, it can be provided to the recording device simultaneously with the data file to be verified. At decision box 63, a determination is made as to whether the data file is authentic. If so, one possible action may be for the device to perform verification to output a message indicating that the data is authentic data from a particular device, as shown in box 64. If the data file is not authentic, i.e., not from the expected data source, a message indicating that the data is not from a particular device may be output.

[0065] In another embodiment, instead of just one key pair, multiple-level keys can be used to make the system more robust to problems by allowing the ability to prove, for example, which device or which type of device was used. For example, in the case of a stolen device that still has keys / certificates internally, a PIN, password, and / or biometrics can be used to enable the use of additional specific keys. A device can have several keys for signing and verification. For example, in a system for verifying that a data stream comes from a specific recording device, one key can be a device key, meaning it comes from, for example, a physical unclonable function (PUF) in the device. A second key can be shared among all devices of the same type, for example, all cameras of the same model produced in the same factory in the same year. Another key can be associated with all cameras of a specific model (from all factories and any year). Yet another key embedded in the device can be associated with all products made by the same manufacturer. In this example, four different keys are proposed, and in another exemplary embodiment, there can be more or fewer than four keys. In this way, any device from the same manufacturer will be able to verify an input (e.g., a photo) with different degrees of certainty and thus produce an output such as "This photo was generated by a device of the same model and the same manufacturer, but not by the device used for verification."

[0066] In another embodiment, the device can use the randomness from the PUF in the device to generate a pair of encryption keys. The public key can be published in the cloud service of the device manufacturer or any other publicly available similar service, such as a key server (like the key servers used in the GNU privacy guard (GPG) or pretty good privacy (PGP) systems). The public key can also be published in a blockchain to ensure the integrity of the record chain. In this case, any person having a record they want to verify can access the service containing the public key of the device, find the device by its ID, and perform the verification either by downloading the public key and performing the verification on their computer or by submitting the file (to be verified) to a public service that will perform the verification in the cloud. The ID of the device can be published in a public repository along with the key, and it can also be attached as metadata to the files produced by the device. Note that these two techniques can be combined together to increase the robustness of the system.

[0067] If the device has multiple symmetric keys embedded in the device by the manufacturer (several devices must know the same key), then the manufacturer will know the keys and will potentially be able to deceive the system to some extent. However, once the deception is discovered, its reputation will be damaged, and the same type of problem now appears in the field of authentication authorities whose business is to keep some keys secret and sign the identities of other parties.

[0068] If the data file is modified, resized or cut into multiple parts, the original device will not be able to check its validity. The complete file must be provided. It is possible to partially solve this problem. Instead of signing the entire file, the device can generate several signatures of its parts. In addition, in the case of a copyright dispute in order to find out who the original author is, the original device and the owner of the record can provide the complete file (the unmodified version of the file).

[0069] There is another way to implement the same functionality, i.e., the functionality that can be used to verify whether a record was created by it. This can be done by using a large secure storage device. The idea includes storing a copy of each file recorded by the device in an internal secure memory that cannot be erased or modified from the outside. This method will require a large amount of memory. Therefore, instead of storing the actual file, it is possible to store a compressed hash version of each file (e.g., only 256 bits per file). Such a method (storing hashes) will still require an internal secure memory in the SoC, but a much smaller memory will be suitable. In this case, no secret key is required in the SoC, and no digital signature needs to be saved in the file. Only the hash can be stored in the device itself and used during verification. If the hash of the verified file exists in the camera, then the image was taken by the camera.

[0070] Figure 6 A simplified system-on-chip (SoC) 70 according to an embodiment is shown. The SoC 70 includes a hardware accelerator 71, an encryption hardware accelerator, a central processing unit (CPU) 73, a PUF circuit 74, and a random number generator circuit 57. The hardware accelerator may include one or more graphics processing units (GPUs) and / or digital signal processors (DSPs). The SoC 70 can be implemented in a recording device or other device to perform a method for verifying the authenticity of a data source.

[0071] As an example, a photo camera uses the hardware accelerator 71 (e.g., GPU and DSP) to create an image based on the captured data. An encryption hardware accelerator 72 is provided to perform encryption algorithms, e.g., digital signature or MAC process. The physical unclonable function 74 and the RNG circuitry 75 are used in the encryption operation. The PUF 74 can be used to generate encryption keys, e.g., key pairs 14 and 26. The same PUF will always generate the same key, while using different PUFs can be used to generate different keys, which can be used to increase security.

[0072] Note that the encryption algorithm can be implemented in the software / firmware of the device, but this will make it much slower and may not be suitable for the time constraints of the application (e.g., taking a picture with a camera would take too long). Importantly, different recording devices have different encryption keys. However, if a PUF is used, it is highly unlikely to generate the same key. In one embodiment, the processing SoC includes an encryption component and components for processing the raw input such that it is very difficult for the encryption component to sign raw data that does not come from the chip itself. The key can also be extracted once from the PUF and then stored in a special secure memory or secure element. In one embodiment, the PUF cannot be read or accessed from outside the chip. In this way, the generation and source of the encryption key will be entirely contained within the SoC, preferably inside the secure element.

[0073] Each embodiment or portion of an embodiment may be implemented in hardware or as instructions on a non-transitory machine-readable storage medium, the non-transitory machine-readable storage medium including any mechanism for storing information in a machine-readable form such as a personal computer, laptop computer, file server, smartphone, or other computing device. The non-transitory machine-readable storage medium may include volatile and non-volatile memories such as read-only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage media, flash memory, etc. The non-transitory machine-readable storage medium does not include transitory signals.

[0074] Although the invention has been described herein with reference to specific embodiments, various modifications and changes can be made without departing from the scope of the invention as set forth in the appended claims. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of the invention. No benefit, advantage, or solution to a problem described herein with respect to a specific embodiment is intended to be critical, required, or essential feature or element of any or all the claims.

[0075] Furthermore, as used herein, the term "a" is defined as one or more than one. Also, the use of introductory phrases such as "at least one" and "one or more" in the claims should not be construed to imply that the indefinite article "a" introducing another claim element limits any particular claim containing such introduced claim element to an invention having only one such element, even when the same claim includes the introductory phrase "one or more" or "at least one" and an indefinite article such as "a". This also applies to the use of the definite article. The terms "circuit" and "circuitry" may refer to hardware, software, or a combination of hardware and software.

[0076] Unless otherwise stated, terms such as "first" and "second" are used arbitrarily to distinguish elements described by such terms. Therefore, these terms are not necessarily intended to indicate a temporal or other precedence of such elements. As used herein, the term "coupled" is not intended to be limited to direct or mechanical coupling.

Claims

1. A method, characterized in that include: Generate a key; Receive a digital certificate; Creating a signed certificate using the digital certificate and the key; storing the signing certificate in a secure element of a recording device; as well as A data stream is received by the recording device and signed using the signing certificate.

2. The method according to claim 1, characterized in that The digital certificate is a Qualified Electronic Signature (QES) certificate provided by the eSign application of the electronic Identification, Authentication and Trust Services (eIDAS) token.

3. The method according to claim 2, characterized in that Creating the signed certificate from the QES certificate and the secret key includes signing the secret key with the QES certificate in a dispensing device.

4. The method according to claim 3, characterized in that Also includes: generating, by the dispensing device, a hash of the signed certificate; transmitting, by the provisioning device, the hash of the signed certificate to the eIDAS token; signing, by the eIDAS token, the hash of the signing certificate to create a signed signing certificate; storing the signed signature certificate in the secure element of the dispensing device; transferring the signed signature certificate from the dispensing device to the recording device; as well as The data stream is signed by the recording device using the signed signing certificate.

5. The method according to claim 4, characterized in that The eIDAS token includes a near field communication (NFC) interface for communicating with a NFC interface of the dispensing device.

6. The method according to claim 1, characterized in that The key is a private key of an asymmetric key pair.

7. The method according to claim 6, characterized in that Also included is using a public key of the asymmetric key pair to verify the authenticity of the data stream.

8. The method according to claim 1, characterized in that: The data stream includes one or more of audio, photo and video information.

9. The method according to claim 1, characterized in that: The dispensing device is a smartphone and the recording device is one of a camera, headphones, a video recorder, or a diagnostic device.

10. A method for verifying the authenticity of a data source, characterized in that: The method comprises: Generate a key pair; Receive a digital certificate; combining the private key of the key pair with the digital certificate to create a signed certificate; generating a hash of the signing certificate; The hash of the signing certificate is signed by a certificate authority; storing the signed and hashed signature certificate in a secure element of the recording device; receiving, by the recording device, a data stream from the data source and signing the data stream with the signed and hashed signature certificate; and The authenticity of the data stream is verified using a public key of the asymmetric key pair.

Images