Method of authenticating an audio signal and web browser extension

Abstract

A method of authenticating an audio signal of a media file associated to a web page is provided. The method comprise the steps of selecting a web page by a user via a web browser, wherein the web page has content with at least one media file comprising an audio signal, wherein said content is stored on a web server. Said audio signal comprises a plurality of audio blocks each having authentication information or authentication access information related to information how or where to retrieve externally stored authentication information. The method further comprising the steps: receiving the audio signal from the web server, extracting or retrieving the authentication information for the audio blocks, and performing an authentication check for the audio blocks of the received audio signal based on the authentication information, and displaying a result of the authentication check via the web browser.

Description

[0001] Method of authenticating an audio signal and web browser extension

[0002] The present invention relates to a method of authenticating an audio signal as well as a web browser extension.

[0003] In view of modern capabilities of creating deep fake video and deep fake audio, the need as arisen to be able to verify or authenticate an audio signal or a video signal like a speech of a politician, etc.

[0004] Until now, it has been very difficult to authenticate an audio signal of a person. Typically, a lot of manual research must be done in order to verify or authenticate such an audio signal and to verify the source of the audio signal.

[0005] It is therefore an object of the invention to provide a method of authenticating an audio signal as well as a web browser extension which are able to perform the authentication of an audio signal and to display the authentication result in a user-friendly manner.

[0006] This object is solved by a method of authenticating an audio signal according to claim 1 as well as a web browser extension according to claim 5.

[0007] Therefore, a method of authenticating an audio signal of a media file associated to a web page is provided. A web page is selected by a user via a web browser. The web page has content with at least one media file comprising an audio signal. Said content is stored on a web server. Said audio signal comprises a plurality of audio blocks each having authentication information or authentication access information related to information how or where to retrieve externally stored authentication information. The method comprises the steps: receiving the audio signal from the web server, extracting or retrieving the authentication information for the audio blocks, and performing an authentication check for the audio blocks of the received audio signal based on the authentication information. A result of the authentication check is displayed via the web browser. According to an aspect the steps of receiving the audio signal from the web server, extracting or retrieving the authentication information for the audio blocks, and performing an authentication check for the audio blocks of the received audio signal based on the authentication information, are performed in a web browser, a web browser extension or a web browser plug-in.

[0008] According to an aspect, method of authenticating an audio signal is provided. The audio signal can be part of a media file that is associated to a website which a user has accessed via a web browser. The media file including an audio signal is stored on the web server. The authenticable audio signal comprises a plurality of audio blocks each having authentication information or authentication access information regarding where and howto retrieve externally stored authentication information. The authentication information is extracted from the audio block or is retrieved via the authentication access information. An authentication check is performed on the retrieved audio signal by a web browser extension and the result of the authentication check is displayed via the web browser. Hence, the authentication check is performed in the web browser extension.

[0009] This is advantageous as there is therefore no need to implement the verification on each website individually and no need to change the website or the web browser as all of the authentication processing is performed by the web browser extension. The authentication result can for example be forwarded to the web browser via an API. The web browser can then display the authentication information on the display of a user or via a user interface.

[0010] According to an aspect, the method of authenticating an audio signal comprises the step determining from the authentication information or the authentication access information the owner of a private key that has originally signed the audio signal and display the owner name to the user of the web browser.

[0011] According to an aspect, the method of authenticating an audio signal the web browser displays the current, time dependent status of the result of the authentication check.

[0012] According to an aspect, the method of authenticating an audio signal comprises the web browser displays the result of the authentication check over time for a whole analysed sequence. According to an aspect, the method of authenticating an audio signal comprises the web browser explicitly marks the occurrence of several blocks with a negative authentication result.

[0013] According to an aspect, the method of authenticating an audio signal comprises the steps of detecting cuts in the received or extracted audio signal, where shortened sequences of the plurality of audio blocks each having authentication information or authentication access information are consecutively put together, and displaying the occurrence of those cuts to the user of the web browser.

[0014] According to an aspect, the method of authenticating an audio signal comprises first inspecting said audio signal whether it comprises authentication information or authentication access information, an if no authentication information or authentication access information is detected, playing back the selected media file without displaying a result of an authentication check via the web browser.

[0015] According to an aspect, the method of authenticating an audio signal comprises first inspecting said audio signal whether it comprises authentication information or authentication access information, and if no authentication information or authentication access information is detected, playing back the selected media file via the web browser and displaying an information about the missing authentication to the user.

[0016] According to an aspect of the invention, a web browser or web browser extension is provided, which are being configured to access a web page that provides content with at least one media file comprising an audio signal, wherein said content is stored on a web server, wherein said audio signal comprises a plurality of audio blocks each having authentication information or authentication access information related to information how or where to retrieve externally stored authentication information, receive the audio signal from the web server, extract or retrieve the authentication information forthe audio blocks of the received audio signal, and perform an authentication check forthe audio blocks of the received audio signal based on the authentication information. A result of the authentication check is displayed via the web browser.

[0017] According to an aspect, a web browser extension is provided, which is configured receive an audio signal to be authenticated, to extract or retrieve the authentication information for the audio block, and perform an authentication check for the audio blocks of the received or extracted audio signal based on the authentication information, and to output a result of the authentication check to web browser associated with the web browser extension.

[0018] The authentication information can be embedded into respective audio blocks of the audio signal. Alternatively, in the audio blocks, only authentication access information are stored. When the web browser extension extracts the authentication access information, it receives information how and where the actual authentication information can be retrieved.

[0019] Once the authenticator in form of a web browser extension has received the authenticating information for the respective audio blocks, the authenticator can perform the authenticating check. If all audio blocks of the audio signal have been authenticated, then the authenticator can forward this information e.g. via the API to the web browser, which is able to display this information on a user interface.

[0020] Alternatively, if there are some audio blocks of the audio signal for which no authentication could be performed, this information can also be forwarded from the authenticator via the API to the web browser to be displayed on the user interface.

[0021] When the authenticator (i.e. the web browser extension or the web browser) has performed the authenticating check of the audio signal, the result thereof can be also displayed via the web browser. Advantageously, the result of the authentication can be displayed in the vicinity of the position on the display where the media file or the link to the media file is arranged. This is advantageous as the result of the authentication can be displayed close to the position of the media file or close to the representation of the media file on the web page. Accordingly, an easy and user friendly way is presented for the verification or authentication of media files comprising audio signals in or on a web page.

[0022] An authenticator is provided for example in form of a browser extension or a plug in for a browser. The authenticator analyses media files in or on a website to be displayed by the web browser to determine the authenticity of an audio signal of the media file. The authenticator determines block boundaries of the audio blocks and the audio signal extracts or retrieves the authentication information associated with the audio blocks and performs the authentication check for each audio block.

[0023] If the audio signal or part of the audio signal (audio blocks) have been authenticated, the authenticator can output a notification via the web browser. If not all audio blocks have been authenticated, this can also be outputted via the web browser. Those audio blocks which have not been authenticated can be marked.

[0024] A web browser is an application (like a software application) allowing an access and interaction with websites on the internet. The web browser is able to retrieve web pages from servers and displays them on your device. To access a web page a web address (e.g. URL) or to search for content online, the web browser connects to the web server that hosts the site, downloads the content (text, images, videos, audio files), and renders the content on a display.

[0025] A web browser extension is a software module or a software program that can be added to a web browser to extend its functionality. Extensions allow users to customize their browsing experience by adding features, improving usability, or integrating with other services.

[0026] Web browser extensions are available for most major web browsers and can be installed from the browser's extension store or marketplace. They run in the background and interact with the accessed web pages to provide enhanced functionality. A web browser extension enhances or customizes the user experience by adding features or altering the behavior of the web browser itself. Extensions work within the browser’s user interface and usually modify how web pages are displayed or add extra functions.

[0027] A web browser plug-in is a software component that adds specific capabilities to a larger software application. Historically, web browser plug-ins were used to handle specific types of content that browsers couldn’t natively support, such as playing video, viewing PDFs, or running Flash or Java content. Modern browsers have largely phased out the need for plugins by supporting these features natively.

[0028] Web browser extensions can be built using standard web technologies like HTML, CSS, and JavaScript and can be browser specific. Plug-ins are typically third-party software, often installed to provide functionality that the browser itself is not able to support on its own.

[0029] Plug-ins are becoming obsolete. Browsers like Chrome and Firefox have stopped supporting most plug-ins, except for a few essential ones like PDF viewers, because modern browsers now natively support most multimedia formats. There are several alternatives to using a web browser extension for achieving similar functionalities, depending on your needs. These alternatives can operate outside the browser or through different means of integration.

[0030] Instead of using a browser extension, standalone apps can offer the same features.

[0031] As an alternative to web browser extensions web services can be used. A website can offer online tools or features that work similarly to extensions but without needing to install anything.

[0032] Audio features relate to an audio representation of an audio signal trying to capture relevant aspects for human auditory perception of the audio signal. The audio features should be selected to reduce the required data rate (for the transmission of the audio features) and hence storage space required on a server. Although the audio features could possibly be the original audio signal itself, preferably the audio features can be a transparently coded version of the original signal requiring much less storage space. Another example for audio features could be the output of any model mimicking the human auditory perception. The audio features can be a Mel-frequency power spectrum of an audio signal with Mel Frequency Cepstral Coefficients (MFCCs).

[0033] According to an example, a computer program product for authenticating an audio signal is provided. The computer program product comprises program code means causing the above described web browser extension to carry out the above described method.

[0034] These and other aspects of the invention are described in more detail with reference to the following figures.

[0035] Fig. 1 shows a block diagram of an audio signal signing module,

[0036] Fig. 2 shows a diagram of an overall audio signing and authentication workflow,

[0037] Fig. 3. shows a block diagram of an audio signal authenticator,

[0038] Fig. 4 shows a block diagram of an audio signal signing module,

[0039] Fig. 5 shows a block diagram of an audio signal authenticator,

[0040] Fig. 6 shows a block diagram of an audio signal signing module,

[0041] Fig. 7 shows a block diagram of an audio signal authenticator, and Fig. 8 shows a flow chart of a method of authenticating an audio signal.

[0042] According to an example, an authentication is performed for an audio signal. The audio signal is authenticated based on information embedded in the audio blocks of the audio signal. The information embedded in the audio blocks can be authentication information directly embedded into the audio block e.g. be means of watermarks or authentication access information. The authentication access information contains information on where and how stored authentication information relating to an audio block can be retrieved from a memory, like a server. In this case the authentication information is not directly embedded in the audio blocks. The Figs. 1 to 5 relate to the example of using authentication access information and the Figs. 6 to 7 relate to the example of using the authentication information.

[0043] According to an example, the authentication of an audio block is performed. Only if not all audio blocks were authenticated then those not authenticated audio block can be analysed further as described below in more details.

[0044] In order to better understand the authentication of an audio signal first of all the generation of the authenticable audio signal is described.

[0045] Fig. 1 shows a diagram of an audio signal signing module. The audio signal signing module 500 receives an input audio signal 121 via an audio input 502 from a microphone 100 or another audio source such as an audio recorder and outputs an output audio signal 501 via an audio output 190. The output audio signal 501 can be based on the input audio signal 121. The microphone 100 can comprise at least one microphone capsule 110 and an ana- log-to-digital AD converter 120. The at least one microphone capsule 1 10 can capture an audio signal and can output a captured analogue audio signal 1 11. The captured analogue audio signal 111 can be forwarded to the analog-to-digital AD converter 120 which can digitize the audio signal 11 1 and can output a digital audio signal 121. The audio signal signing module 500 can be implemented as a device separate from the microphone 100 or can be comprised in the microphone 100.

[0046] The audio signal signing module 500 can receive the audio signal 121 from the microphone 100 or from another source, which is indicated in Fig. 1 by the selector 101 . The digital audio signal 121 is inputted to a block divider 130 which divides the audio signal 121 into audio blocks 131 and outputs a sequence of a plurality of audio blocks 131. Optionally, if the audio signal 121 is already divided into audio blocks 131 , the block divider 130 can be omitted. The sequence of audio blocks 131 are forwarded to an audio feature extractor 150 which generates audio features 151 for each audio block 131 in the sequence of audio blocks. A private key signature unit 140 receives authentication information comprising audio features 151 of each audio block 131 togetherwith optional further information 1 13 (e.g. metadata) like location or time and signs the authentication information with the private key 142, providing signed authentication information 141 , which can be stored on a memory 600 e.g. located on an external server. The signed authentication information 141 can comprise the authentication information 152 (see Fig. 2) comprising audio features 151 and optional further information 1 13 and a signature 144 (Fig. 2) generated by the private key signature unit 140. Alternatively, the authentication information 141 can be stored in an internal memory or any other memory, as long as it can be accessed by an authenticator used to authenticate a received audio signal.

[0047] The signed authentication information 141 itself comprises the authentication information, namely (a) audio features 151 , optionally (b) the further information 113 and (c) the signature 144. The individual audio blocks 131 are e.g. in parallel fed to an information embedder 160 for embedding authentication access information 162 e.g. into each audio block 131. The authentication access information 162 comprises information on where and / or how the authentication information 152 (or more precisely the signed authentication information 141), for that particular audio block 131 , can be accessed at the memory 600 e.g. on a server. The embedding can for instance be accomplished by means of watermarking.

[0048] Hence, the information embedder 160 can be implemented as a watermark generator which generates a watermark 163. Another option is to embed the authentication access information 162 into an appropriate audio container next to the actual audio blocks 131. Accordingly, the information embedder 160 outputs audio blocks 161 with embedded authentication access information 162. The output of the embedder 160 corresponds to the output audio signal 501 of the module 500 at the audio output terminal 190. The output audio signal 501 can be broadcasted or stored e.g. via a network 300 (Fig. 2). In particular, it can be even further modified to a little extent, including modification types like sample rate conversion, perceptual compression and cutting.

[0049] In the case that the information embedder 160 is a watermark generator its output 161 could alternatively be input to the audio feature extractor 150 instead of the original audio blocks 131 , which is indicated in Fig. 1 by the selector 102. This alternative offers the advantage that the audio features are extracted based on the final signal 161 that will be output by the audio signal signing module 500 rather than an intermediate signal 131 that is not outputted. As the watermark generator is designed to perceptually alter an audio signal as little as possible, both input options (131 or 161) for the audio feature extractor 150 are reasonable.

[0050] Audio features relate to an audio representation trying to capture the relevant aspects for human auditory perception and at the same time preferably reduces the required data rate and hence storage space required on the server or memory 600. Although it could possibly be the original audio signal itself, preferably it can be a transparently coded version of the original signal requiring much less storage space. Another example for audio features could be the output of any model mimicking the human auditory perception.

[0051] The audio signal 501 (with the embedded watermark or authentication access information included in an audio container) at the output of the audio signal module 500 can be stored or transmitted. As a watermark can be embedded into e. g. substantially each audio block 131 , each audio block 131 can be individually authenticated. The watermark 103 can also be embedded only in some of the audio blocks. The watermark 163 can comprise apart from the authentication access information further information like the block boundaries. This information can be used when authenticating the audio signal to determine a block length.

[0052] An audio watermark 163 can be a distinct identification which is embedded in an audio signal and which is for example previously used for identifying a copyright information of the audio signal. Preferably, the watermark is embedded into the audio signal such that it becomes very difficult to remove or destroy the watermark. Preferably, if the audio signal with the embedded watermark is copied, stored or transmitted, the embedded watermark will not change. The same reasoning applies to authentication access information included in an audio container.

[0053] Fig. 2 shows a diagram of an overall audio signing and authentication workflow. An audio signal is captured by a microphone 100 outputting a digital audio signal 121 . From this audio signal 121 audio features 151 are extracted and signed with the private key 142 of e.g., audio signal signing module 500. The audio features 151 together with the digital signature 144 generated by the signature unit 140 form the signed authentication information 141. The signed authentication information 141 can be forwarded to a server or memory 600, where the signed authentication information 141 is stored for later retrieval. The information on where and / or how the signed authentication information 141 can be retrieved, namely the authentication access information 162 is provided for the audio signal signing module 500. The audio signal signing module 500 uses this authentication access information 162 and embeds this information into the audio blocks 131 of the audio signal. Hence, the output signal 501 of the audio signal signing module 500 comprises the audio blocks 131 with the embedded authentication access information. The audio blocks 131 of the audio signal with the embedded authentication access information 162 are outputted by the audio signal signing module 500 and can be stored or distributed e.g. through a network 300.

[0054] This distribution can involve a modification or manipulation of either the authentication information 152 and / or the audio signal 121 . The signed authentication information 141 is validated using the public key 143. This validation indicates a potential modification of the audio features. By extracting audio features from the received signal and comparing them with the features contained in the signed authentication information 141 the integrity of the audio signal can be verified. A final authentication result 261 is determined from both checks.

[0055] An audio signal signing module 500 e.g. implemented as part of a microphone 100 is used to capture an audio signal. Alternatively, an audio signal signing module 500 can receive the audio signal. The audio signal can also be an audio signal captured beforehand by other means. As described with reference to Fig. 1 , the captured audio signal is divided into a plurality of audio blocks and the authentication information of at least one audio block is signed based on the private key 142 of the audio signal signing module 500. The signed authentication information 141 is outputted by the audio signal signing module 500 and can be stored on a server or memory 600. Authentication access information 162, regarding information where the authentication information can be retrieved from the server or memory 600 can be provided to the audio signal signing module 500. The authentication access information 162 is embedded into the audio block received or captured by the audio signal signing module 500. Thus, the audio signal signing module 500 outputs a) an output audio signal 501 , which comprises audio blocks with embedded authentication access information to a network 300 for storing or forwarding and b) signed authentication information 141 to the server or memory 600 where this information ca be stored.

[0056] Optionally, the authentication access information can be embedded into the audio blocks of the audio signal by means of a watermark. The watermark can relate to authentication access information relating to a location of a memory 600 where authentication information is stored. This authentication information can be generated by an audio feature extractor 150 as described above with reference to Fig. 1 . The audio blocks of the audio signal with the embedded authentication access information can be transmitted via a network 300 or stored. An authenticator 200 can receive the audio signal 501 with the embedded watermark and extract the authentication access information. The authentication information is retrieved from the server 600 based on the authentication access information. The signature of the authentication information as stored on the server or memory 600 can be validated based on a public key 143 associated to the audio signal signing module 500 which can be stored, for example, on a server 400 or a distributed ledger.

[0057] Fig. 3 shows a block diagram of an audio signal authenticator. The audio signal authenticator 200 receives an audio signal 171 with embedded authentication access information. This audio signal 171 ca be the output audio signal 501 from the audio signal signing module 500 of Fig. 1. This audio signal 171 is input into a block bounds detector and block divider 205, which determines block boundaries and outputs a plurality of audio blocks 201 with embedded authentication access information 212. If the authentication access information 212 has been embedded by means of watermarking, it is assumed that the block boundaries have been previously coded into the watermark, from which they can be detected at this stage. In case the audio signal is transported by an audio container that contains the authentication access information 212 as metadata, it is assumed that the authentication access information is available per block with the block boundaries being part of the metadata.

[0058] The audio blocks 201 with embedded authentication access information are input into the access information extractor 210, which extracts the authentication access information 212 (corresponding to the authentication access information 162 from the signing modules if no manipulation has taken place) from the audio blocks 201 . The authentication access information interpreter 230 determines access information from the authentication access information 212 namely, where to find the signed authentication information 141 belonging to the current audio block 201 on a server or memory 600. The authentication information 141 retrieved from the server or memory 600 comprise firstly audio features 151 representing the audio block 201 , secondly the signature 221 and thirdly optional further information 113 like location and / or time where and / or when the signing has taken place. The signature 221 corresponds to the signature 144 generated by the signature unit 140 if no manipulation has taken place.

[0059] In a perceptual similarity analyzer 240 the audio blocks 201 and the audio features 151 are perceptually compared to each other, providing a similarity statement 241. In the simplest case this can be a binary decision about whether the compared quantities are perceptually sufficiently equal or not. Alternatively, the similarity statement 241 can be more detailed, proving for instance a similarity score.

[0060] In the similarity analyzer 240 the audio blocks can be compared to the audio features of the original audio signal. The audio features can be a true copy of the original audio signal. This will however require large storage space to store the original audio signal. If the audio features relate to other characteristics of the original audio signal, the similarity analyzer should compare the received audio features with the audio features of the audio signal to be authenticated. Hence, the required audio features can be extracted from the audio signal to be authenticated. This can be performed e.g. in the similarity analyzer. In other words, the similarity analyzer should compare the audio features (as received via the authentication access information, i.e. the audio features of the original audio signal) and corresponding audio features of the audio signal to be authenticated.

[0061] An authentication access information interpreter 230 further determines from the authentication access information 212 which owner of the private key 142 has originally signed the audio signal 171 , e.g. represented by an ID. The owner of the private key 142 can be a natural person, an organization, a registered microphone to name only a few possibilities. Using this ID, a public key 143 and the identity 270 of the owner of the private key can be retrieved from an external database. The public key 143 is subsequently employed to verify the combination of the signature 221 and the authentication information 152 (the audio features 151 and the further information 113) within a signature verifier 250, proving a signature verification result 251. The perceptual similarity statement 241 and the verification result 251 are finally combined in a combiner 260 to a final authentication result 261 .

[0062] Note that the processing that is here proposed for audio content can be similarly applied to any time dependent data. In particular, it can be also applied to video content, if the following modifications are applied, i.e. the microphone 100 is replaced by a video camera, the audio feature extractor 150 is replaced by a video feature extractor, the authentication access information embedding unit 160 uses a visual watermark instead an audio watermark, or uses a video container instead of an audio container and the auditory perceptual comparison 240 is replaced by a visual perceptual comparison.

[0063] Fig. 4 shows a schematic block diagram of a more general audio signal signing module compared to that shown in Fig. 1 . In particular, as opposed to the diagram illustrated in Fig. 4, it is here not specified by which means the individual audio blocks and the corresponding authentication information are distributed, potentially independently from each other, as long as it is possible to access both components at the verification step.

[0064] The audio signal signing module 500 receives a digital audio signal 121 at its audio input 502, which is inputted to the block divider 130 which outputs a sequence of plurality of audio blocks 131. The audio blocks 131 are forwarded to an audio feature extractor 150 which generates audio features 151 for each audio block 131. In a private key signature unit 140, authentication information comprising audio features 151 of each audio block 131 together with optional further information 113 like location or time is signed with the private key 142 of a user or entity, providing signed authentication information 141. The signed authentication information 141 itself consists of the audio features 151 , the generated signature 144 and the optional further information 113. Both components, the individual audio blocks 131 and the signed authentication information 141 are required during the verification of the authentication method shown in Fig. 5. They can be in principle embedded into the same suitable audio container, but can also be distributed over different physical channels. Optionally, a user or entity identifier 145 can be added to both components, which can for instance enable the retrieval of the suitable public key for an automated verification.

[0065] Fig. 5 shows a schematic block diagram of a more general authenticator 200 corresponding to the signal signing module depicted in Fig. 4. The authenticator 200 receives an audio signal e.g. in form of audio blocks 201 which are to be verified as well as signed authentication information 141. The signed authentication information 141 comprises audio features 151 , further information 113 and the signature 221 . The audio features 151 contained in the authentication information 141 are perceptually compared to the audio blocks 201 within the perceptual similarity analyzer 240, providing a similarity statement 241. In the simplest case this can be a binary decision about whether the compared quantities are perceptually sufficiently equal or not. Alternatively, the similarity statement 241 can be more detailed, providing for instance a similarity score. Further, with knowledge about the user or entity that created the signature 221 , the corresponding public key 143 and optionally the user identity 270 are obtained. Optionally, this knowledge can be derived from a user or entity identifier 145 provided together with the authentication information 141 and the audio blocks 201 . The public key 143 is subsequently employed to verify the combination of the signature 221 and the authentication information 141 within the signature verification block 250, proving a signature verification result 251 . The perceptual similarity statement 241 and the verification result 251 are finally combined in combiner 260 to a final authentication result 261 . In the following Fig. 6 generation of an authenticable audio signal based on embedding authentication information into the audio blocks as well an authentication of the audio signal based on the embedded authentication information is described. This authentication can be used in the authentication of an audio signal as described in the following.

[0066] Fig. 6 shows a diagram of an audio signal signing module. The audio signing module of Fig. 6 is merely an example of an audio signing module. The audio signal signing module 500 receives an input audio signal 121 via an audio input 502 from a microphone 100 or another audio source such as an audio recorder and outputs an output audio signal 501 via an audio output 190. The output audio signal 501 can be based on the input audio signal 121. The microphone 100 can comprise at least one microphone capsule 110 and an ana- log-to-digital AD converter 120. The at least one microphone capsule 1 10 can capture an audio signal and can output a captured analogue audio signal 1 11. The captured analogue audio signal 111 can be forwarded to the analog-to-digital AD converter 120 which can digitize the audio signal 111 and can output a digital audio signal 121 .The audio signal signing module 500 can be implemented as a device separate from the microphone 100 or can be comprised in the microphone 100.

[0067] The audio signal signing module 500 can receive the audio signal 121 from the microphone 100 or from another source, which is indicated in Fig. 6 by the selector 101 . The digital audio signal 121 is inputted to a block divider 130 which divides the audio signal 121 into audio blocks 131 each having a block length and outputs a sequence of a plurality of audio blocks 131 . The block divider 130 can divide the audio signal 121 into a plurality of audio blocks. Optionally, the audio blocks each receive a block number, which can be a subsequent block number. Optionally, if the audio signal 121 is already divided into audio blocks 131 , the block divider 130 can be omitted. The sequence of audio blocks 131 are forwarded to an audio feature extractor 150 which generates audio features 151 for each audio block 131 in the sequence of audio blocks 131 . A private key signature unit 140 receives authentication information comprising audio features 151 of each audio block 131 together with optional further information 113 (e.g. metadata) like location or time and signs the authentication information with the private key 142, providing signed authentication information 141. The signed authentication information 141 can comprise the authentication information 152 comprising audio features 151 and optional further information 113 and a signature 144 generated by the private key signature unit 140. The signed authentication information 141 itself comprises the authentication information, namely (a) audio features 151 , optionally (b) the further information 113 and (c) the signature 144. The individual audio blocks 131 are e.g. in parallel fed to an information embedder 160 for embedding the signed authentication information 141 e.g. into each audio block 131. The embedding can for instance be accomplished by means of watermarking.

[0068] Hence, the information embedder 160 can be implemented as a watermark generator which generates a watermark 163. Another option is to embed the signed authentication information 141 into an appropriate audio container next to the actual audio blocks 131. Accordingly, the information embedder 160 outputs audio blocks 161 with embedded signed authentication information 141 . The output of the embedder 160 corresponds to the output audio signal 501 of the module 500 at the audio output terminal 190. The output audio signal 501 can be broadcasted or stored e.g. via a network 300 (Fig. 7). In particular, it can be even further modified to a little extent, including modification types like sample rate conversion, perceptual compression and cutting.

[0069] In the case that the information embedder 160 is a watermark generator its output 161 could alternatively be input to the audio feature extractor 150 instead of the original audio blocks 131 by the selector 102. This alternative offers the advantage that the audio features are extracted based on the final signal 161 that will be output by the audio signal signing module 500 rather than an intermediate signal 131 that is not outputted. As the watermark generator is designed to perceptually alter an audio signal as little as possible, both input options (131 or 161) for the audio feature extractor 150 are reasonable.

[0070] The audio signal 501 (with the embedded watermark or authentication access information included in an audio container) at the output of the audio signal module 500 can be stored or transmitted. As a watermark can be embedded into e. g. substantially each audio block 131 , each audio block 131 can be individually authenticated. The watermark 103 can also be embedded only in some of the audio blocks. The watermark 163 can comprise apart from the authentication information further information like the block boundaries. This information can be used when authenticating the audio signal to determine a block length.

[0071] An audio watermark 163 can be a distinct identification which is embedded in an audio signal and which is for example previously used for identifying a copyright information of the audio signal. Preferably, the watermark is embedded into the audio signal such that it becomes very difficult to remove or destroy the watermark. Preferably, if the audio signal with the embedded watermark is copied, stored or transmitted, the embedded watermark will not change. The same reasoning applies to authentication access information included in an audio container.

[0072] Fig. 7 shows a block diagram of an audio signal authenticator corresponding to the audio signal authenticator of Fig. 6. The audio signal authenticator 200 receives an audio signal 171 with embedded authentication information. This audio signal 171 can be the output audio signal 501 from the audio signal signing module 500 of Fig. 6. This audio signal 171 is input into a block bounds detector and block divider 205, which determines block boundaries and outputs a plurality of audio blocks 201 with embedded authentication information.

[0073] The block bounds detector and block divider 205 detects the block boundaries e.g. by means of information in the block headers. As the block lengths of the audio blocks can vary the block lengths should be determined for each audio block or for a group of audio block having the same block length.

[0074] The audio blocks 201 are inputted to an authentication information extractor 206 which extracts signed authentication information 141 embedded in the audio blocks, which can comprise audio features 151 , a signature 144 and thirdly optional further information 1 13 like location and / or time where and / or when the signing has taken place. The signature 221 corresponds to the signature 144 generated by the signature unit 140 if no manipulation has taken place.

[0075] In a perceptual similarity analyzer 240 the audio blocks 201 and the audio features 151 are perceptually compared to each other, providing a similarity statement 241. In the simplest case this can be a binary decision about whether the compared quantities are perceptually sufficiently equal or not. Alternatively, the similarity statement 241 can be more detailed, proving for instance a similarity score.

[0076] An authentication information extractor 206 further determines from the authentication information 113 / 141 which owner of the private key 142 has originally signed the audio signal 171 , e.g. represented by an ID. The owner of the private key 142 can be a natural person, an organization, a registered microphone to name only a few possibilities. Using this ID, a public key 143 and the identity 270 of the owner of the private key can be retrieved from an external database. The public key 143 is subsequently employed to verify the combination of the signature 144 and the authentication information 152 (the audio features 151 and the further information 113) within a signature verifier 250, proving a signature verification result 251 . The perceptual similarity statement 241 and the verification result 251 are finally combined in a combiner 260 to a final authentication result 261 .

[0077] Note that the processing that is here proposed for audio content can be similarly applied to any time dependent data. In particular, it can be also applied to video content, if the following modifications are applied, i.e. the microphone 100 is replaced by a video camera, the audio feature extractor 150 is replaced by a video feature extractor, the authentication access information embedding unit 160 uses a visual watermark instead an audio watermark, or uses a video container instead of an audio container and the auditory perceptual comparison 240 is replaced by a visual perceptual comparison.

[0078] Fig. 8 shows a flow chart of a method of authenticating an audio signal. In step S1 , an audio signal to be authenticated is selected. The audio signal can be part of a media file that is associated to a web page of a website which a user has accessed via a web browser. The media file including an audio signal is stored on the web server. The authenticable audio signal comprises a plurality of audio blocks each having authentication information or authentication access information regarding where and how to retrieve externally stored authentication information. In step S2, the authentication information is extracted from the audio block or is retrieved via the authentication access information. In step S3, an authentication check is performed on the retrieved audio signal by a web browser extension. In step S4 the result of the authentication check is displayed via the web browser.

[0079] The authentication result can for example be forwarded from a web browser extension to the web browser via an API. The web browser can then display the authentication information on the display of a user or via a user interface.

[0080] The authentication information can be embedded into respective audio blocks of the audio signal. Alternatively, in the audio blocks, only authentication access information are stored. When the web browser extension extracts the authentication access information, it receives information where the actual authentication information can be retrieved.

[0081] Once the authenticator in form of a web browser extension has received the authenticating information for the respective audio blocks, the authenticator can perform the authenticating check. If all audio blocks of the audio signal have been authenticated, then the authenticator can forward this information via the API to the web browser, which is able to display this information on a user interface. If some audio blocks of the audio signal for which no authentication could be performed, are present, this information can also be forwarded from the authenticator via the API to the web browser to be displayed on the user interface.

[0082] When the authenticator (i.e. the web browser extension or the web browser) has performed the authenticating check of the audio signal, the result thereof can be also displayed via the web browser. Advantageously, the result of the authentication can be displayed in the vicinity of the position on the display where the media file or the link to the media file is arranged. This is advantageous as the result of the authentication can be displayed close to the position of the media file or close to the representation of the media file on the web page. Accordingly, an easy and user friendly way is presented for the verification or authentication of media files comprising audio signals in or on a web page.

[0083] A web browser or a web browser extension can implement an authenticator according the examples above and in particular the Fig. 3, 5 and 7.

[0084] A web browser is an application for accessing websites. When a user requests a web page from a particular website, the browser retrieves files from a web server and displays the page on a display of a user. The purpose of a web browser is to retrieve content from the web or local storage and display this content on the user’s device. The web browser can based on the information on the web page retrieve the media file and other information from a web server to display a web page on a user interface or a display.

[0085] A browser extension can be a software module for customizing a web browser.

[0086] An authenticator is provided for example in form of a browser extension or a plug in for a browser. The authenticator analyses media files in or on a website to be displayed by the web browser to determine the authenticity of an audio signal of the media file. The authenticator determines block boundaries of the audio blocks and the audio signal extracts or retrieves the authentication information associated with the audio blocks and performs the authentication check for each audio block.

[0087] If the audio signal or part of the audio signal (audio blocks) have been authenticated, the authenticator can output a notification via the web browser. If not all audio blocks have been authenticated, this can also be outputted via the web browser. Those audio blocks which have not been authenticated can be marked. Instead of being implemented in a browser extension the authentication mechanism can also be supported by the browser natively. This still has the advantage that there is no need to modify the websites providing authenticable content but allowing the user to see a verification result.

[0088] One aspect if the invention is to present the result of the authentication check as performed according to one of the embodiments according to Figs. 3, 5 and 7 to a user of a web browser in a convenient way.

[0089] Optionally in step S1 the web browser or the web browser extension can first inspect the selected media file whether it comprises authentication information or authentication access information. If no authentication information or authentication access information is detected, the web browser or the web browser extension can play the selected media file without displaying an authentication information via the web browser. Alternatively, the web browser can in this case display an information about the missing authentication to the user. If authentication information or authentication access information is detected, the web browser can display the result of the authentication check to the user of the web browser together with the selected media file.

[0090] If authentication information or authentication access information is detected, the web browser or the web browser extension can optionally determine from the authentication information the owner of the private key 142 that has originally signed the audio signal and display the owner name registered for this owner to the user of the web browser.

[0091] Optionally the web browser or the web browser extension can at a time display the current, time dependent status of the result of the authentication check. For instance it can show a green mark as long as the authentication result is positive, red as long as the authentication result is negative and yellow or no mark as long as no authentication information is available. Alternatively, the web browser can display the time dependent authentication status of the media file in or close to a symbolic representation of the media file (e.g. the progress bar I timeline of the player) showing the result of the authentication check over time for a whole analysed sequence. In other words, for time dependent media (video and audio) this visualization could contain a representation of a verification measure over time (e.g., file modified from second 3-5 but the rest is unaltered). This allows to easy jump to suspicious parts of the file. If the audio has no Ul representation (“background sound”) then the browser might show this button or representation somewhere in the browser control panel. A further option is to take into consideration for the visualization that in case of a malicious signal manipulation several consecutive blocks will be affected more likelythan just a single one. Hence, it is reasonable to specially mark the occurrence of several blocks with a negative authentication result. This might happen, e.g., by using a darker shade of the red color every time the length of the presumably modified excerpt exceeds a certain length, e.g. 5 sec. Another option would be to increase the darkness of the red tone with the length of the presumably modified excerpt.

[0092] Further, only shortened sequences of an originally signed media file may be used on a website and those pieces may be consecutively put together. Those cuts may or may not alter the meaning of the original recording. For dealing with those cases, the web browser can additionally display the occurrence of those cuts to the user of the web browser. Therefore, if the metadata contains numbers of the authenticated blocks, any occurrence of noncontiguous block numbers could be specially indicated with the authentication results by e.g. a flash or a broken chain link, thereby hinting to a cut in the original signal. In case the audio signal to be authenticated has been created from a composition of different audio signal excerpts, for every excerpt the associated signer (e.g. the owner of the private key, institution or person) may be listed alongside the authentication results. In a simpler version only a list of signers responsible for any excerpt in the given audio signal might be displayed.

[0093] If the belonging authentication information of a media file is available before starting the playback, the web browser may start displaying the result of the authentication check for the whole media file before starting the playback. For streaming media like audio or video the provenance information (or a link to it) is either provided in a way that it is available from the very beginning of the stream (e.g., via meta data) or it could be provided with the individual chunks I blocks of the stream (e.g., via a watermark). In the latter case the displayed information can change over time depending on how much information is already available. This could mean that at the beginning of the stream only a link to a verification service is available while at the time the whole media stream has been received by the browser a more detailed analysis is shown.

[0094] In the above described the similarity analyzer the audio blocks can be compared to the audio features of the original audio signal. The audio features can be a true copy of the original audio signal. This will however require large storage space to store the original audio signal. If the audio features relate to other characteristics of the original audio signal, the similarity analyzer should compare the received audio features with the audio features of the audio signal to be authenticated. Hence, the required audio features can be extracted from the audio signal to be authenticated. This can be performed e.g. in the similarity analyzer. In other words, the similarity analyzer should compare the audio features (as received via the authentication access information, i.e. the audio features of the original audio signal) and corresponding audio features of the audio signal to be authenticated.

[0095] In an example, a watermark may comprise a chronological sequence of a pilot sequence (indicating a beginning of a watermark, a user ID and a block ID). If the watermark is detected and can only be partially decoded (e.g. only pilot sequence, but no meaningful user ID or block ID), it is nevertheless reasonable to notify the user accordingly. An advance user (for example a news agency) may deduce from the information that the content was signed at a certain point in time but seems to have been altered afterwards. The partial presence of the watermark could further be used to refute the claims that the file has never been changed.

[0096] In a further example, if authentication information (providence information) is not bound to the content by a watermark but e.g. via a time-dependent metadata format, there is a possibility that the digital audio workstation references all relevant providence information of all source files with accurate time stamps. In this case, the above described authentication procedure is not necessary since all information is already available.

[0097] According to an example, each audio signal which is captured by the microphone 100 and which is outputted by the microphone can comprise a watermark by means of which it is possible to determine the actual microphone which has captured the audio signal. If the microphone is used by several users, several user IDs can be associated to the microphone. If the microphone is registered, then it is possible to identify the respective microphone. The user IDs can also be registered. The user IDs can be dedicated IDs or sub IDs of the microphone ID. The microphone ID and / or the user IDs can be part of the watermark. By means of the sequence numbers of the audio blocks, it can be determined when part of the audio signal has been removed.

[0098] Optionally, the audio signal could be part of a video file.

[0099] Optionally, the signed authentication information can be included in an audio file (e.g., similar to ADM file format) instead of including it into a watermark. In this case the audio signal may not be modified. Optionally, the process of generating a signed audio signal could be performed in a software solution based on a pre-existing audio recording or an audio stream. The private key can be entered to the software e.g., by dongle, text input, and authorized e.g., by biometric signal like fingerprint or face detection.

[0100] The authentication process can calculate a similarity score between the audio features of the signed audio signal and the analyzed signal. This could allow to determine a likelihood that the signal is still authentic even if minor signal processing like e.g., gain has happened.

[0101] For authentication the audio signal as well as the signed authentication information is needed. The signed authentication information might be provided via a side channel. In case watermarking is used the authentication access information must be read out from the audio signal and the authentication information must be retrieved accordingly. In case the watermarking readout needs the block boundaries one approach to achieve this is to try out different offsets of block boundaries until a successful watermark readout is possible. Another approach could be to embed some synchronization signal with a watermark into the audio signal.

[0102] To enhance the security of the system a process is provided that allows to withdraw keys e.g., in case they are stolen.

[0103] The public keys for authentication can be provided in various ways. One option is to store all public keys in one centralized database to make it easy to find the needed key. To tackle potential trust issues in this central instance the database with all public keys could be provided on a distributed ledger technology. Another option is that the organization / person that uses the technology provides the public key on their own website.

[0104] Further examples of the audio features are described by Torsten Dau, Dirk Pueschel, and Armin Kohlrausch. A quantitative model of the "effective" signal processing in the auditory system. I. model structure. The Journal of the Acoustical Society of America, 99(6):3615- 3622, 1996, in the following referred to as the perception model (PEMO). This paper describes a quantitative model aimed at describing how the auditory system processes acoustic signals. The focus is on developing a model that mimics the functional processing of auditory stimuli as perceived by humans, particularly in the context of complex sounds like speech or music. Key components of the model can include peripheral processing, envelope extraction, modulation filtering and decision stage. The peripheral processing part of the model captures the initial stages of auditory processing, including the transformation of acoustic signals into neural representations through mechanisms such as the outer and middle ear filtering, as well as nonlinearities in the cochlea. The envelope extraction part relates to the extraction of the temporal envelope of sound, which is crucial for understanding amplitude modulation and speech processing. The modulation filtering part relates to a system that filters amplitude modulations, mimicking how the auditory system is sensitive to different modulation frequencies. At the decision stage the processed auditory signal is used to make decisions about the nature of the sound, representing higher-level auditory perception.

[0105] The model was designed to be consistent with experimental psychoacoustic data, particularly in its ability to simulate the auditory system's response to amplitude-modulated sounds. This approach provides a framework for understanding the effective signal processing in human auditory perception, especially for tasks involving the detection and discrimination of complex auditory patterns.

[0106] Carrying out the comparison of the received audio blocks and the extracted or retrieved authentication information in a transformed domain (namely regarding the human auditory perception audio features) ensures that the identified differences are perceptually meaningful. In principle any similarity measure, e.g., the empirical cross-correlation coefficient or the relative error with respect to the reference, may be used to map the result of the comparison onto a numerical value.

[0107] When applying further transformations to the Mel-frequency power spectrum of an audio signal, Mel Frequency Cepstral Coefficients (MFCCs) are. MFCCs use the Mel scale, which is a perceptual scale of pitches which serves to approximate the way humans perceive sound. The Mel scale is nonlinear, such that it spaces out lower frequencies more finely and higher frequencies more coarsely, aligning more closely with human auditory perception.

[0108] Mel Frequency Cepstral Coefficients use the cepstrum as a transformation that converts a signal from the frequency domain back into a domain where the signal's rate of change can be analyzed. The idea is to capture the spectral properties of a signal in a way that emphasizes the information-carrying components. The process to compute MFCCs from an audio signal can involve several steps: Pre-em- phasis: Boosting the high-frequency components of the signal to balance the spectrum, usually by applying a high-pass filter, Framing: The audio signal is divided into short overlapping frames, typically 20-40 milliseconds long. This is because speech signals are non- stationary, but they can be considered quasi-stationary within these short frames, and Windowing: Each frame is multiplied by a window function, such as a Hamming window, to reduce edge effects and smooth the signal. Fourier Transform: A Fast Fourier Transform (FFT) is applied to each windowed frame to convert the time-domain signal into the frequency domain. Mel Filter Bank: The resulting spectrum is passed through a series of triangular bandpass filters spaced according to the Mel scale. This step approximates how humans perceive sound frequencies. Logarithm: The logarithm of the power of each Mel- filtered spectrum is computed. This simulates the human ear's response to loudness, Discrete Cosine Transform (DCT): Finally, the logarithmic Mel spectrum is transformed using the DCT. The result is a set of coefficients called MFCCs. Typically, only the first 12-13 coefficients are kept, as these contain the most important information.

[0109] MFCCs can capture the broad spectral shape of the audio signal in a compact form, making them highly useful for machine learning algorithms in speech and audio processing. They help in distinguishing different phonemes, speaker identities, and other audio characteristics by providing a representation that is robust to variations in pitch, volume, and other factors.

[0110] The audio feature can also comprise:

[0111] 1 . Linear Predictive Coding (LPC) which is a method that represents the spectral envelope of a digital signal of speech in compressed form, using the information from a linear predictive model. It estimates the parameters of a filter that can be used to recreate the signal. LPCs are highly effective for modeling the formants (resonant frequencies) of speech sounds.

[0112] 2. Perceptual Linear Predictive (PLP) Coefficients which is similarto Linear Predictive Coding but incorporates aspects of human auditory perception, such as the critical-band spectral resolution, equal-loudness curve, and intensity-loudness power law. Perceptual Linear Predictive (PLP) Coefficients aims to mimic the non-linear perception of loudness and frequency by the human ear. 3. Gammatone Filterbank Features relate to filterbanks which simulate the filtering that occurs in the human cochlea. They are similar to Mel filterbanks but use Gammatone filters instead of triangular filters. The Gammatone Filterbank Features are useful for capturing the detailed frequency structure of audio, particularly in tasks involving environmental sound classification or hearing aid design.

[0113] 4. Chroma Features, which represent the 12 different pitch classes (C, C#, D, etc.) of a musical octave. They capture harmonic and melodic characteristics of music. These are particularly useful in music information retrieval, key detection, and chord recognition tasks.

[0114] 5. Mel Spectrogram: While similar to MFCCs, a Mel spectrogram is the result of directly applying the Mel filterbank to a power spectrogram without further transformation (like DCT). The Mel spectrogram retains more detailed frequency information and is often used as input to deep learning models and is used in conjunction with Convolutional Neural Networks (CNNs) in tasks like audio event detection, speech recognition, and music genre classification.

[0115] 6. Constant-Q Transform (CQT), which is a time-frequency representation that provides a logarithmic frequency scale, similar to the Mel scale, but with a variable time resolution that matches the frequency resolution. It is particularly useful for musical applications because it provides a better representation of musical pitch than the linear FFT or even the Mel scale.

[0116] 7. Deep Learning-Based Features: Learned features from deep learning models, such as embeddings from a trained neural network, can also be used as an alternative to traditional hand-crafted features like MFCCs. These features are often more robust and can capture complex patterns that are not easily modeled by traditional methods.

[0117] 8. Spectral Subband Centroids (SSC) which captures the centroid of energy distribution in different subbands of the signal, which can be interpreted as the "center of mass" of the spectrum within each subband. It provides information about the distribution of energy across frequency bands and is sometimes used as a complement to MFCCs.

[0118] 9. RelAtive SpecTrAI (RASTA) Features which involves filtering the log energy of the speech signal to emphasize modulation frequencies important for speech recognition. RASTA-PLP is a combination of RASTA filtering and PLP analysis, providing robust features against noise and channel variations. Audio features relate to an audio representation of an audio signal trying to capture relevant aspects for human auditory perception of the audio signal. The audio features should be selected to reduce the required data rate (for the transmission of the audio features) and hence storage space required on a server. Although the audio features could possibly be the original audio signal itself, preferably the audio features can be a transparently coded version of the original signal requiring much less storage space. Another example for audio features could be the output of any model mimicking the human auditory perception. The audio features can be a Mel-frequency power spectrum of an audio signal with Mel Frequency Cepstral Coefficients (MFCCs).

[0119] In particular the audio features can be acoustical characteristics, spectral characteristics, and statistical characteristics of the audio signal.

[0120] Acoustical features can include pitch (Fundamental Frequency); prosody (Rhythm, Stress, Intonation) and / or duration and silence patterns (inconsistencies in pauses, speech timing, or breathing sounds can be used as audio features.

[0121] Spectral Features can include formant frequencies (like resonant frequencies in speech); Mel-Frequency Cepstral Coefficients (MFCCs) (the short-term power spectrum of sound and can reveal artifacts introduced during synthesis or manipulation); spectrogram analysis (a manipulation may exhibit unusual or smeared energy distribution in the time-frequency representation); and / or phase information.

[0122] Acoustical features can include statistical and signal processing features, like noise and residuals (like subtle background noises or artifacts introduced during synthesis may not match natural recordings); high-frequency content; and / or phase distortions (some manipulations may introduce phase anomalies, which can be detected with signal processing techniques).

[0123] Acoustical features can include temporal features, like jitter and shimmer (like frequency and amplitude variations); temporal coherence (like sudden transitions or changes in speech characteristics, like unnatural breaks in the signal).

[0124] Acoustical features can include behavioral or semantic Inconsistencies, like content coherence (logical inconsistencies or unnatural flow in the spoken content might be indicative of manipulation); emotion and naturalness (The emotional tone may not align with the content, or the voice may lack the natural nuances of human emotion). The audio features can be any one of the above mentioned audio characteristics of the audio signal or a combination of them.

[0125] By combining these features with machine learning or signal processing techniques, models can be trained to detect artifacts and inconsistencies indicative of deepfake audio.

Claims

Claims1 . A method of authenticating an audio signal of a media file associated to a web page, comprising the steps of: selecting a web page by a user via a web browser, wherein the web page has content with at least one media file comprising an audio signal, wherein said content is stored on a web server, wherein said audio signal comprises a plurality of audio blocks each having authentication information or authentication access information related to information how or where to retrieve externally stored authentication information, further comprising the steps:- receiving the audio signal from the web server,- extracting or retrieving the authentication information for the audio blocks, and- performing an authentication check for the audio blocks of the received audio signal based on the authentication information, and displaying a result of the authentication check via the web browser.

2. Method of claim 1 , wherein the steps receiving the audio signal from the web server, extracting or retrieving the authentication information for the audio blocks, and performing an authentication check for the audio blocks of the received audio signal based on the authentication information, are performed in a web browser, a web browser extension or a web browser plugin.

3. Method of claim 1 or 2, wherein the display of the authentication check result is arranged in or close to a position of a symbolic representation of the media file comprising the audio signal to be authenticated.

4. Method of claim 1 , 2 or 3, wherein those audio blocks or group of audio blocks for which the authentication check has failed are highlighted on the web browser.

5. Method of any one of claims 1 to 4, further comprising the step: determining from the authentication information or the authentication access information an owner of a private key (142) that has originally signed the audio signal and display the owner name to the user of the web browser.

6. Method of any one of claims 1 to 5, wherein displaying a current, time dependent status of the result of the authentication check via the web browser.

7. Method of any one of claims 1 to 6, wherein displaying the result of the authentication check over time for a whole analysed sequence of the audio signal via the web browser.

8. Method of any one of claims 1 to 7, wherein explicitly marking an occurrence of several blocks with a negative authentication result.

9. Method of any one of claims 1 to 8, further comprising the steps: detecting cuts in the received or extracted audio signal, where shortened sequences of the plurality of audio blocks each having authentication information or authentication access information are consecutively put together, and displaying the occurrence of those cuts to the user of the web browser.

10. Method of any one of claims 1 to 9, further comprising the steps: first inspecting said audio signal whether it comprises authentication information or authentication access information, and if no authentication information or authentication access information is detected, playing back the selected media file without displaying a result of an authentication check via the web browser.11 . Method of any one of claims 1 to 8,, further comprising the steps: first inspecting said audio signal whether it comprises authentication information or authentication access information, and if no authentication information or authentication access information is detected, playing back the selected media file via the web browser and displaying an information about the missing authentication to the user.

12. Web browser or web browser extension being configured to access a web page that provides content with at least one media file comprising an audio signal, wherein said content is stored on a web server, wherein said audio signalcomprises a plurality of audio blocks each having authentication information or authentication access information related to information how or where to retrieve externally stored authentication information, receive the audio signal from the web server, extract or retrieve the authentication information for the audio blocks of the received audio signal, and perform an authentication check for the audio blocks of the received audio signal based on the authentication information, and display a result of the authentication check via the web browser.

13. Web browser extension being configured to received an audio signal to be authenticated, extract or retrieve authentication information for audio blocks of the received audio signal, and perform an authentication check for the audio blocks of the received audio signal based on the extracted or received authentication information, and output a result of the authentication check to web browser associated with the web browser extension.

14. Computer program product for authenticating an audio signal, wherein the computer program product comprises program code means causing the web browser or a web browser extension according to claim 12 to carry out the method of any one of the claims 1 to 11 .

Images