Zum Hauptinhalt springen
tsecurity.de LIVE
Echtzeit-Radar & Feeds
Alle RSS Feeds
👥 Community & Social
Web Security TippsIntroducing the new Confluence integration with Google Chat(22.09.2026 um 19:40 Uhr)
Web Security TippsQuick notes in Take notes for me(22.09.2026 um 21:31 Uhr)
Sichere ProgrammierungSecurity improvements for SSH(22.09.2026 um 16:11 Uhr)
Sichere ProgrammierungKI-Akzeptanz: Wie Rewe digital einfach nur den Chatbot umbenannte(22.09.2026 um 18:00 Uhr)
Sichere ProgrammierungClaude Opus 5.5: Keeping safety ahead of capabilities(22.09.2026 um 20:59 Uhr)
Sichere ProgrammierungYour Terraform Monolith Isn't Too Big. It's Tightly Coupled.(22.09.2026 um 21:00 Uhr)
Sichere ProgrammierungMy PR got merged into Mike — OSS Legal AI Platform 🎉(22.09.2026 um 21:34 Uhr)
Sichere ProgrammierungStop Writing JavaScript To Fix `100vh` On Mobile(22.09.2026 um 21:35 Uhr)
Sichere ProgrammierungNext.js proxy.ts Explained (with Cheat Sheet)(22.09.2026 um 21:36 Uhr)
Web Security TippsIntroducing the new Confluence integration with Google Chat(22.09.2026 um 19:40 Uhr)
Web Security TippsQuick notes in Take notes for me(22.09.2026 um 21:31 Uhr)
Sichere ProgrammierungSecurity improvements for SSH(22.09.2026 um 16:11 Uhr)
Sichere ProgrammierungKI-Akzeptanz: Wie Rewe digital einfach nur den Chatbot umbenannte(22.09.2026 um 18:00 Uhr)
Sichere ProgrammierungClaude Opus 5.5: Keeping safety ahead of capabilities(22.09.2026 um 20:59 Uhr)
Sichere ProgrammierungYour Terraform Monolith Isn't Too Big. It's Tightly Coupled.(22.09.2026 um 21:00 Uhr)
Sichere ProgrammierungMy PR got merged into Mike — OSS Legal AI Platform 🎉(22.09.2026 um 21:34 Uhr)
Sichere ProgrammierungStop Writing JavaScript To Fix `100vh` On Mobile(22.09.2026 um 21:35 Uhr)
Sichere ProgrammierungNext.js proxy.ts Explained (with Cheat Sheet)(22.09.2026 um 21:36 Uhr)
Intelligence View
⚡ tsecurity.de Intelligence

Addressing The Threat of Deep Fakes With Trusted Devices and Public Key Infrastructure

Introduction I've got a bold claim, but it's one I'm willing to stick by: We can neutralize some of the gravest threats posed by deepfakes, and we can do it using existing technology platforms and a little bit of cooperation. To get…

0
↗ Quelle (dev.to)
Reagiere als Erste:r — dein Feedback zählt!




Introduction



I've got a bold claim, but it's one I'm willing to stick by: We can neutralize some of the gravest threats posed by deepfakes, and we can do it using existing technology platforms and a little bit of cooperation.



To get straight to the point: We're massively over-investing in detecting and/or stenographically watermarking deepfakes. It is far easier to digitally sign authentic images using Public Key Infrastructure (PKI), and then use the digital signature to verify the authenticity of the image.



It's a relatively simple solution, and I'll explain what it means in more detail shortly. It's so simple, in fact, that it's surprising that it isn't the mainstream approach already.



I believe there are two main reasons why:

(1) There is currently no compelling way to stop bad actors from digitally signing inauthentic images.

(2) We need a widespread, highly available and trusted mechanism that allows the public to verify digitally signed images themselves.



This blog post proposes a solution to both of these problems. Neither solution is purely technological. In fact, the solution can't be purely technological because it involves notions of trust. Perhaps that is why, as a society, we have been unable to muster an effective response - as frayed as our trust in institutions has become. As such, this post is as much of a guide as it is a clarion call as technologist to cooperate to solve this problem, and start to rebuild trust in our society - different and better.






The Solution - In Short



There are three legs to the stool.




  1. Trusted Devices With Integrated Hardware Security Modules (HSMs)

  2. Public Key Infrastructure

  3. Browser Integration



I am defining Trusted Devices as digital cameras with a Hardware Security Module (HSM) directly integrated with the camera sensor. When an image is captured by the camera sensor, the HSM uses a certificate from a "Trusted Device Root Certificate" (TDRC) to digitally sign the image. In order to authenticate the image, the digital signature can be easily verified as having been produced by a valid TDRC-deriving certificate, therefore marking it as an authentic image.



In other words, every image captured by the Trusted Device can be verified as having been produced by the camera sensor of a Trusted Device, as long as:




  • The TDRC is not compromised

  • The individual certificate granted to the device is not compromised

  • The HSM has not been tampered with and/or somehow extracted from the Trusted Device



The Public Key Infrastructure already has measures in place to handle compromised certificates, mitigating the first and second risks. HSMs are already widely deployed and have a variety of tamper-resistant designs, mitigating the third risk. I would be unsurprised if there are HSM designs that make them completely inoperable outside of their intended hardware environment. If such guarantees do not presently exist in HSMs, I have an intuition that they could be implemented without too much difficulty.



So, that covers the Trusted Devices and Public Key Infrastructure.

Here's the last part that brings it all together: the browser.



The browser is the perfect platform for instantly assessing the authenticity of an image. It's widespread, trusted, and already deeply integrated with the PKI. And it was literally designed to display pictures.



Hacking together a Chromium build to verify digitally signed images would be the easy part:




  • You add the TDRC to the list of root certificates

  • Add some code to automatically detect TD signatures in image metadata, and then verify the signature using the PKI.

  • Indicate to the user that the image being displayed is authentic



The difficult part is finding a way to make the value of the "signal of authenticity" effortlessly understandable and un-spoofable.



The lock icon on the address bar is one example of a successful deployment of a similar concept - you can't fake the lock icon with CSS because the address bar isn't in the page. However, images are in the page - and you need the mark of authenticity to be closely associated with the image. So, it would be natural to, say, "overlay" the image with some kind of special icon. But how can we "mark" the image as authentic in a way that can't be replicated by a clever front-end engineer?



I am tempted to propose some specific solutions, but I feel I would be out of my lane. Browsers employ talented UX people, and I don't want to poison the well with a bad suggestion. Suffice it to say that I think the problem is solvable, and would involve some combination of within-page indicators and out-of-page indicators. But perhaps there is another obvious solution which involves just one or neither? I would love to hear some of your ideas in the comments.






The Perfect Is The Enemy of the Good



Who should be distributing Trusted Devices to everybody? Dear technologist, I'm going to share my beliefs on this point, but I'm going to break with accepted wisdom in a way that may at first seem dangerous and naive.



In short, my claim is that Trusted Devices should not be widely distributed or purchasable by consumers. Instead, they should be distributed to persons and organizations we have good reason to trust. But, before you accuse me of suggesting that we create a "Ministry of Truth", allow me to make my case.



My argument has three parts:

(1) Limiting usage of Trusted Devices to certain important societal functions would solve a problem which currently has no good solution.

(2) Widespread availability of Trusted Devices would damage the credibility of the system through misuse.

(3) The standard retort of "who watches the watchmen" needlessly invalidates the public good that trust-based institutions provide.






Limiting Trusted Devices To Trusted People



If Trusted Devices are not widely available, who might use them, and for what purposes? Here are some examples:



1) A highly regarded journalist documenting atrocities and genocides.

2) Courts and congresses recording government business "for the record".

3) Notaries and local officials recording official proceedings.

4) Licensed and accredited 3rd party agencies gathering photographic evidence for criminal cases, claims, and lawsuits.



To wit, expanding on (4), I could easily imagine the creation of "Trusted Device Holders Licensing Board", where an individual, after being accredited and background checked, would be granted a Trusted Device and License. They would derive their livelihood from providing verifiable photographic evidence using Trusted Devices as a service to the public, and would have a vested interest in using honestly due to the threat of license revocation (which would correspond with revocation of the device's certificate and loss of income).



If you're uncomfortable with yielding any amount of trust, let's consider the alternative. Imagine the financial chaos if insurance adjustors begin deepfaking images of property to show no damage, in order to avoid paying claims. Or the collapse of jurisprudence when no photographs can be submitted as evidence because any image might be deep-faked. Or the innumerable abuses of the truth possible under despotic tyranny.



My claim is that the only reasonable remedy here to allow for the distribution of Trusted Devices to actors and institutions who are already generally trustworthy, or can be made trustworthy because it is in their best interest to act in a trustworthy fashion (i.e.; notary-like functions).



What's more, the remedy






The Potential For Misuse of Trusted Devices With General Distribution



Trusted Devices should not be widely distributed or purchasable by the public because they have an obvious griefing-vector. The owner can take an authentic photograph of an inauthentic image. I.e.; generate a deep-fake, print it out at very high resolution on very good paper, light the room completely neutrally, and take a photo.



I doubt that there is a durable and practical way to detect this type of workaround. To me, this indicates that at a certain level, you have to trust the owner of the device.



You might argue that if we are required to trust the owners of devices in order to trust the authenticity of the image, this is no better than our current situation.



I emphatically disagree: In the world where trusted actors own Trusted Devices, we would have a small population of producers of images that are 99.99% guaranteed to be real - and a way to promptly deal with any bad actors if they act in a provably dishonest way.



(As an aside, if the circumstances permit, proving the dishonesty would be straightforward: Have two other Trusted Device owners take a photograph proving the first photograph was inauthentic)



That's a much better spot than we are currently in. Presently there's just one class of image, and we are reliant wholly on the public already frayed trust. With the requisite self interest to fake an image in abundant supply around every corner, wouldn't the arrangement I describe be much better?






Multi-Level Certificates for Scalable Enforcement Against Misuse



In order for the benefits of Trusted Devices to be felt at multiple levels in society (down the local level, for example), there has to be a certain level of hierarchical distribution and ownership, and therefore hierarchical levels of accountability for the misuse of devices.



Therefore, it may be worthwhile to create sub-certificates under the TDRC corresponding to the hierarchy of organizations owning the Trusted Devices. This would be paired with a policy which revokes the higher level certificate if enough abuses at the lower level. This aligns the interests of all the individual actors in the Trusted Device ecosystem with the greater public good of having a trustworthy system.






Quis custodiet ipsos custodes?



The standard libertarian retort to granting any kind of trust to any institution is that the institution will inevitably act in its own self-interest and betray the sacred trust. After all, "Who watches the watchmen?"



It's a powerful argument, and there's some truth to it.



But let's think about the situation by way of analogy: A village ruler, unable to find a ironclad way to keep the guardsmen watched, decides that it would be better if there were no guardsmen at all! (Or institutes a system that is completely secure but so burdensome that the guardsmen are ineffective).



The king is not wrong to fear the guard, but misjudges where the balance of the threats lie. Leaving the castle unguarded is far worse than yielding a measured amount of trust to a useful institution. Reasonable measures can be taken to ensure the trustworthiness of the guard. It's not perfect, but it's better.



For the being being (until we inevitably get our collective asses handed to us), technologists are the rulers of our own domains. Let's not be foolish rulers. Let's not betray the trust places in us by insisting on unrealistic levels of purity.






Increasingly Dangerous Tigers Kept By Underfunded Zookeepers



You might still be convinced that detecting or watermarking deep-fakes is the way forward. Google seems to think so, perhaps disingenuously.



You will have to pardon me for being blunt, but I think this position is laughable.



Think of deepfakes like zoo animals:



Deepfakes are either "captured" or "escaped". They are "captured" if they are detectable (via algorithm, stenography, or watermark). They are "escaped" if they are not.



What does it take for a deepfake to "escape"? Removal of the stenography (easy), removal of the watermark (easy), and/or improvement of deep-fake fidelity past the point of detectability.

The detectability point is the most concerning, because it feels inevitable: the quality of generative AI is actually defined by how well it can escape a detector. The very advancement of the field is tied to beating detectors. Any quality deepfake detector will simply be used a benchmark to beat by the next model.



So, being in the safety field in AI is bit like an arms race between underfunded cage builders and ever-more-dangerous tigers. And in a very direct way, making a great deep-fake detector only furthers the arms race and makes the problem worse.






Practicalities



We understand the problem. We have the technology to address it.


The problem is that implementing the solution takes cooperation between Public Key Infrastructure, Browser Vendors, and HSM Manufacturers.



Of the three parties involved, HSMs are the most commercially minded and therefore would require a traditional business relationship between the initiative and the HSM vendor. As such, substantial funds may need to be involved. What's more, it might be prudent to have multiple vendors to avoid supply chain attacks on the integrity of the system.



It's unclear to me if the economic incentives required to implement the system currently exists, but I have an inkling that the general difficulties caused by rampant deepfakes may create a sort of public incentive to get the problem solved.



But by that point it may be too late. Relationships with organizations whose interests would align with a successful implementation could be cultivated now. For example, a company that is not well positioned to dominate AI but instead position themselves to address AI's dangers. Apple and Google come to mind. What's more, both are also major browser vendors (Safari and Chrome).



Reaching out to browser standards organizations like W3C seems like necessary as well, but perhaps the way to exert influence there is to work through Apple and Chrome.






Summary



The plan is simple. Produce Trusted Devices that leverage PKI to produce digitally signed images. Push out a browser update that indicates to the average user that an image is verifiable and verified. Encourage the development of trust-based institutions through licensing and careful distribution for Trusted Devices.



I'm sure that others have had similar ideas. There are already partial realizations of similar ideas through organizations like DocuSign. I would not at all be discouraged if the idea or a very similar one has already been proposed or even attempted - I would consider that validation.



Credit for intellectual originality is nice, but I'd much rather have the credit for cultivating the collective will to make this thing a reality. If this blog post helps make this system a reality, then originality or lack thereof be damned, I'll be happy for it.

Ähnliche Beiträge
🔍 Verwandte News

Auch interessante Nachrichten Addressing The Threat of Deep Fakes With Trusted Devices and Public Key Infrastructure

Thematisch verwandte Begriffe: Addressing, Threat, Deep, Fakes · 6 Treffer

Laden...

Videos werden geladen ...

Laden...

Beiträge werden geladen ...

Laden...

Videos werden geladen ...

Laden...

Beiträge werden geladen ...

Laden...

Videos werden geladen ...

Laden...

Beiträge werden geladen ...

Laden...

Videos werden geladen ...

Laden...

Beiträge werden geladen ...

Laden...

Videos werden geladen ...

Zum Aktualisieren ziehen
ZERO-DAY CVE-2026-77259 | MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian pro…
Advisory →
TTS Reader • tsecurity.de Voice
tsecurity.de Icon
tsecurity.de App
Offline-Lesen, Eilmeldungen & 0ms Ladezeit

Installiere tsecurity.de direkt auf deinen Home-Bildschirm für das ultimative Vollbild-Magazinerlebnis ohne Browser-Leisten.

Nächster Beitrag
Themen-Radar & Intelligence Matrix
Echtzeit-Taxonomie nach Angriffsvektoren & Plattformen

tsecurity.de Live Threat Radar

🔴 LIVE RADAR
MONITORING
AKTIV
CVE-DATENBANK
LIVE
🔍
Community Radar & Live Chat
Sentinel Bot online • Live-Stream
Dein Cluster: Security Explorer
Match:
lädt…
Verbindung zum Community-Stream wird aufgebaut...
Bearbeitungsmodus — Senden überschreibt deine Nachricht
Community-Puls — was gerade passiert
lädt…
Aktivitäten deiner Analysten
lädt…
Neues Thema oder Eilmeldung einreichen

Reiche interessante Links, Zero-Days oder Debatten ein. Die Community entscheidet per Upvote über die Veröffentlichung.

Heiß diskutierte Einreichungen
🔖 Gespeicherte Artikel
📂 Keine gespeicherten Artikel vorhanden.
Zurück Ziehen Vor
Links: vorheriger Artikel Rechts: nächster Artikel unten: schließen
News NIS-2 Frühwarnung Tier-1 Intel ⏱️ 3 Min vor 10 Min
Artikeldaten werden geladen...

Zurück: vorheriger Vor: nächster
↗ Original-Quelle
Social Reaktionen Deine Reaktion zählt
Einstufung & Relevanz-Poll 0 Stimmen
In sozialen Netzwerken teilen 1-Klick