Dmitri Alperovitch
@dmitri.silverado.org
29K followers 870 following 530 posts
Geopolitics, Russia, China, Cyber Chairman @silverado.org Author of WorldOnTheBrink.com Host GeopoliticsDecanted.com podcast Founder Alperovitch Institute for Cybersecurity Studies at Johns Hopkins SAIS Co-Founder CrowdStrike @DAlperovitch elsewhere
Posts Media Videos Starter Packs
Pinned
dmitri.silverado.org
Very proud to have my #WorldOnTheBrink with @vermontgmg.bsky.social named as one of the best books of 2024 by the @economist.com!
www.economist.com/culture/2024...
dmitri.silverado.org
I haven’t. What do you think has changed primarily?
Reposted by Dmitri Alperovitch
hvanderaxe.bsky.social
Very interesting podcast by @dmitri.silverado.org why drones are a useful addition to the European military but shouldn't be the main focus for investment in building our military capabilities.
Why Drones Can’t Replace Traditional Firepower
Geopolitics Decanted by Silverado · Episode
open.spotify.com
Reposted by Dmitri Alperovitch
zathras5.bsky.social
Justin Bronk — @justin-br0nk.bsky.social — is a keen observer of military affairs. Talking with @dmitri.silverado.org, he challenges the view that Ukraine’s success with UAVs against Russia is a model for what the US and other western nations should focus on. podcasts.apple.com/us/podcast/g...
Why Drones Can’t Replace Traditional Firepower
Podcast Episode · Geopolitics Decanted by Silverado · 08/05/2025 · 49m
podcasts.apple.com
dmitri.silverado.org
Hopefully we made it clear on the podcast!
dmitri.silverado.org
Why Drones Can’t Replace Traditional Firepower

My @GeopolDecanted discussion with @justin-br0nk.bsky.social about his recent provocative @rusi.bsky.social piece on this topic.

We also discuss efficacy of Ukrainian F-16s, Operation SpiderWeb and much more. Watch 👇

youtu.be/ykLIH2kY1U8
Why Drones Can’t Replace Traditional Firepower
YouTube video by Dmitri Alperovitch
youtu.be
dmitri.silverado.org
The key is to keep the implementation as simple as possible (attestation via Intel Trust Authority or mTLS) and not include poison pills like kill switches and geofencing that would make this unworkable and too onerous for end-users and chip designers alike

END
dmitri.silverado.org
Through this lens, the Chip Security Act or similar solutions would help accomplish the goal of identifying export control violators with minimal overhead to AI chip companies and exporters
dmitri.silverado.org
The goal here would not be to identify and stop every AI chip export violation but to collect additional data that might help identify export control violators
dmitri.silverado.org
In another scenario, if you have a customer that has purchased tens of thousands of AI chips which are not reporting in every month (accounting for typical chip failure rates, etc), it is also grounds for a BIS investigation of an importer
dmitri.silverado.org
A typical hop between eg Shanghai and Singapore will add 40-300ms of consistent latency which can be easily detected. This would then be a clue for BIS to investigate further
dmitri.silverado.org
To mitigate against this, the exporter's webserver can measure round trip time (RTT) for packets inside the mTLS connection and then compare it to pings to the IP from which the connection is originating
dmitri.silverado.org
Of course, this is not full-proof. Chinese companies can purchase AI chips through shell companies elsewhere, reship the chips to China and then proxy their mTLS connections through VPNs and proxies in countries where the shell companies are based
dmitri.silverado.org
Another way to accomplish this might to be use existing Intel Trust Authority for GPU remote attestation architecture that Intel and Nvidia have partnered on but that creates a requirement to use Intel CPUs, which may not be ideal in every case docs.trustauthority.intel.com/main/article...
GPU Remote Attestation With Intel® Trust Authority | Intel® Tiber™ Trust Authority
Learn about the Intel® Trust Authority Python Client, CLI for Intel TDX and NVIDIA GPU, and Intel Trust Authority REST API that support GPU attestation.
docs.trustauthority.intel.com
dmitri.silverado.org
GPU drivers can already do mTLS handshake operations like ECDSA signing, so this doesn’t even require any new code from the chip designers
dmitri.silverado.org
The connection can be trivially initiated via a simple script from other parts of the environment where the AI chip is deployed, but just talk to the GPU driver for handshake initiation/client key exchange with the EXPORT_CERT. This minimizes the technical reqs for AI chips
dmitri.silverado.org
The mTLS connection would not originate from the chip itself. In fact, it doesn’t even have to originate from the server that the chip is in
dmitri.silverado.org
So if a chip is being sold to a data center in Singapore but the connection originates from an IP address in China (or anywhere else), well, that means you might have a potential transshipment on your hands that warrants BIS investigation
dmitri.silverado.org
The US exporter would then have the country from where the secure mTLS conn is originating from and match it against the customer KYC and export info data that they had been collected during the export process to determine whether country of shipment matches country of use
dmitri.silverado.org
US exporters would run mTLS webservers with public key versions of the EXPORT_CERTs loaded on them (they would get them from the chip designers) to record the IP addresses and their geolocation from where the connections are originating
dmitri.silverado.org
Foreign end-users (wouldn’t apply to US customers or perhaps to trusted foreign govs) would then be obligated by BIS to use this cert for mTLS (mutual-auth) Client Key Exchange connection generation to the US exporter of the chip on a periodic basis (ex. once a week/month)
dmitri.silverado.org
New AI chips going forward can incorporate a new certificate with a private key (EXPORT_CERT) in their Secure Enclave (they already have other certs for secure boot/attestation). So this is a very simple task
dmitri.silverado.org
Here is one technical solution for chip location verification that can be easily implemented by AI chip designers, which is not onerous and won’t require GPS receivers or comms functionality inside the chip or significantly restrict its use in air gap environments👇