TPM provides zero practical security(gist.github.com) |
TPM provides zero practical security(gist.github.com) |
The reason there is no explicit threat model defined in the TPM specs is because it defines a general-purpose hardware security module. It is up to integrator to define the threat model (TPM's security properties also depend on the rest of the system) and the application.
Even if a TPM is not perfect and depends on other pieces of the puzzle to also be secure, it at least opens the possibility of making it secure in the future once those vulnerabilities are discovered & fixed. Furthermore, even in this vulnerable state, it still increases the effort required for a successful attack.
Support for TPM-backed full disk encryption means you can now have FDE on by default for everyone with no usability impact at all. Even if it's not secure and a dedicated attack will still break it, it means a casual attacker can't just pull a drive or reboot the machine and run chntpw or steal sensitive data from discarded drives that haven't been properly wiped.
I like TPMs. I like the fact that a rogue datacenter employee or intruder can't just pull one of my servers' drives out and get sensitive data. I like not having to worry about having sensitive keys on the filesystem somewhere because every secret is in memory and is ultimately derived from the TPM doing remote attestation at boot and handing ephemeral keys. I like not having to worry about unattended reboots or entering LUKS passphrases remotely.
There's no reason to believe this will require a TPM or depend on the presence of one. As far as I know, Widewine and similar DRM schemes successfully achieved this without any hardware assistance. Yes, bypasses exist and all the major piracy groups have them, but the objective of preventing the masses from having access to a working bypass is clearly achieved and doesn't require hardware.
But in such a scenario, an attacker can also use such an attack to bypass any remote attestation/DRM/etc!
I guess you could argue that such attacks are too much work for consumers, and that low fences control big dumb animals…but I think, fundamentally, the same argument applies to consumer security functions like FDE!
Tl;dr: I think it’s hard to argue that TPMs are both useless for practical user security and a threat to free computing. It’s gotta be one or the other!
Will this stop a dedicated attacker? Probably not, although a fTPM with an up to date OS would require the attacker to find an exploit for this machine's early boot firmware (UEFI, etc) or burn a Windows zero-day, both of which are very costly.
It does however prevent your casual thief from watching a YT video "how to reset windows password using linux live cd" and then getting access to your sensitive data (browser's saved passwords, etc), so it's a major improvement.
Yes, there are a lot of vulnerabilities in the Secure Boot process on most devices, because the surface area is huge, but the attacker still needs _some sort_ of vulnerability to gain a foothold.
I agree with the frustration in the gist - Secure Boot and TPM-sealed disk encryption aren't nearly as good as they could be, because the surface area is gigantic and sure to get exploited. But this is a classic Security Nerd vs Reality scenario: while it is absolutely _possible_ to pwn Secure Boot + TPM-sealed encryption in almost any scenario, using it still makes it _much harder_ for an attacker to do so, and most will give up.
I'm not sure if this is what Windows actually does, though, or if the TPM just hands over the disk encryption key after Windows passes system attestation and then verifies the screen unlock PIN/password in software – that would be significantly less secure.
The only thing I do not get is why this is not done by a simple SIM card like in any mobile phone. Then one could choose a TPM. Even more: I do not get why I cannot encrypt my android phone with my SIM card.
Hi, it's me the Linux fanboy whose entire personality is making Hackintosh and VM apps for iOS. Just a friendly reminder that attacks on the author's credentials have no baring on the weight of the arguments.
> The reason there is no explicit threat model defined in the TPM specs is because it defines a general-purpose hardware security module
It sounds like you have zero experience in security :)
> it defines a general-purpose hardware security module
No it doesn't. I think you're hinting at HSM which is another beast I may write another fanboy FUD piece about at some point. But no, HSMs are not the same as TPMs. And TPMs are not HSMs. For one thing, and HSM defines something called a trust boundary where keys should never leave. TPMs will happily hand you the keys when you meet a certain condition. HSMs support key migration and provides a secure way to transfer keys from one HSM to another without leaving the trust boundary. I can go on and on...
> TPM's security properties also depend on the rest of the system
The argument isn't TPM versus no security. The argument is TPM versus the existing security you have on Windows. (Passwords, FDE, etc). Of course all this depends on the system. TPM doesn't add anything (* with the exception already listed in the article).
> it at least opens the possibility of making it secure in the future once those vulnerabilities are discovered & fixed
Nope. Architecturally flawed. But I'd just be repeating the argument from the article.
> means a casual attacker can't just pull a drive or reboot the machine and run chntpw or steal sensitive data from discarded drives that haven't been properly wiped
They can with a $80 FPGA. Read the appendix.
> I like the fact that a rogue datacenter employee or intruder can't just pull one of my servers' drives out and get sensitive data.
They can with a $80 FPGA. (Unless your datacenter uses Intel TXT and tboot and other prerequisites that were talked about in the article)
> I like not having to worry about having sensitive keys on the filesystem somewhere
If you use BitLocker, they are always in kernel memory
> derived from the TPM doing remote attestation at boot
That's not what "remote attestation" means :)
> I like not having to worry about unattended reboots or entering LUKS passphrases remotely
If you like that, just disable your password and you'll get the same result
You can create non-exportable keys on TPM's, and there are mechanisms to securely transfer keys between devices.
Granted, doing so is kind of a mess, but nonetheless possible.
> It sounds like you have zero experience in security :)
Seems like you're countering an ad hominem with an ad hominem here...?
I don't know the TPM specifications in detail myself, but I do know that TPMs are in fact quite general-purpose HSMs, of which assisting in attestation/measurements for the purpose of trusted computing is only one (although certainly the most controversial) subfeature.
If I can store my SSH keys on my TPM and just don't use trusted computing at all... How is that "zero practical security"?
Congrats and thanks as I'm fairly sure I must've used your work at some point.
> Just a friendly reminder that attacks on the author's credentials have no baring on the weight of the arguments.
I didn't check nor care about the author nor their credentials because my comment was purely on the piece itself and what it sounded like to me and not an ad-hominem to the author. It did after all contain the usual scary terms such as "Microsoft", UEFI, Secure Boot as well as dismisses an entire concept just because of some flaws that can be rectified incrementally.
> It sounds like you have zero experience in security :)
I never claimed to be a security expert, but maybe my layman's approach allows me to overlook the pedantry and avoid dismissing something entirely just because it doesn't perfectly conform to some ideals? (I think the TPM's threat model will be up to the integrator to determine, as it depends on other things such as discrete vs firmware TPM, UEFI/Option ROMs and their security flaws, etc).
> No it doesn't.
I used "HSM" to mean "dedicated hardware device that does security-related things", rather than a 1-to-1 equivalent of a commercial HSM. But to the best of my knowledge a TPM can also act as a (low-throughput) actual HSM if you so desire, allowing operations with a secret key without ever disclosing it?
> The argument is TPM versus the existing security you have on Windows. (Passwords, FDE, etc)
My argument is that the TPM enables frictionless FDE for the masses without any change in user experience and without even relying on a password (which would often be weak and thus useless in practice).
Tell me how this is the same level of security as no FDE or FDE with weak password. Even if it can be broken using various methods (some of which you've described), surely you see that it still significantly increases the barrier to entry and cost of a successful attack?
> They can with a $80 FPGA. (Unless your datacenter uses Intel TXT and tboot and other prerequisites that were talked about in the article)
Those machines use fTPM which isn't vulnerable to this attack, but regardless, $80 is still more expensive than the $1 a Linux live-CD/USB costs, not to mention the requirement for lengthy physical access and ability to solder/connect wires onto the mainboard.
I'm not arguing that TPM is unbreakable or will resist sophisticated, prepared, targeted attackers. But it raises the bar by at least $80 (and in practice by a lot more on modern machines with fTPM), with zero additional effort from the user (thus it can even be used where conventional passworded FDE is impractical, such as unattended servers). It's literally free security, and yet you chose to shit on it just because it's not perfect (even though the flaws would get patched up over time, as with any product).
I think it would be good if this level of security could become the baseline (even if it's not perfect) and would rather not have FUD getting in the way. You are of course welcome to use something stronger depending on your requirements, but this becoming the baseline is still an improvement over no FDE at all (still seems to be the norm on PCs).
> If you use BitLocker, they are always in kernel memory
Yes I understand, it would still means you'd need to either be root already or have a privilege escalation exploit to extract them.
I'm not necessarily talking about FDE keys here though (for FDE keys, if you can execute code just read the filesystem directly, no need to even care about the FDE).
TPM allows a machine to prove (with reasonable levels of security, requiring at least $80 to break) to another one that it's in a given state, and be able to obtain ephemeral credentials based on that claim, this avoiding needing to persist those anywhere.
> That's not what "remote attestation" means :)
See above.
> If you like that, just disable your password and you'll get the same result
Well no, because then any guy with a Linux live CD can get the data (or someone at the recycler if the drives are swapped and discarded without being sanitized), where as now they'd at least need to shell out 80 bucks plus a soldering iron and lengthy & suspicious-looking physical access to the machine.
It seems like it's a sunken cost fallacy that big tech spent a lot of money on and they are trying to get it back by convincing average Joe that a TPM is good for your PC.
I thought the piece was ok, but it doesnt add anything new. its another piece pointing at the puzzle a lot of people including you already know exists. its not aimed at you for that matter. (so fair comments, but perhaps a bit harsh?)
If somebody that wants your data steals your PC he will be likely to find a way to access your personal data. It's a protection against a casual thief that is probably not interested in your data and can't probably even figure out how to bypass the Windows password screen.
But if this doesn't make harm, why not have it? Because having disk encryption enabled by default to a user that doesn't know that is enabled by default is not necessary a good thing. Let's face it: users don't do backups. I know even companies that have all their data on a single server with no backups.
Now if the motherboard breaks and you don't have backup... you can't just take the disk out of that computer, connect to another PC and recover the data. You have lost your data!
But wait, you say Microsoft tought about that, indeed if you signed in with a Microsoft account you can recover your Bitlocker encryption key from the Microsoft portal... wait what? Exactly. No security at all! Microsoft knows your encryption keys and it stores it on their servers... again: false sense of security is worse than no security at all!
Finally, even if this system was 100% secure: do you trust the hardware? The same hardware produced by the same manufacturer of the products where nearly once in a year a big security flaw is discovered? The same hardware where we know that the NSA, and probably other government agencies, placed backdoors?
Whatever, typing a password when booting up the computer (that is once in a day) is such a big deal?
Can't you alternatively also export a copy of the actual disk encryption key and write that on a piece of paper? The last time I used Windows, that was possible, at least (but I think I didn't use the TPM back then).
On macOS, you can do either, for example, and it uses a similar construction (although using Apple's proprietary secure element and hardware encryption engine rather than a TPM and secure boot).
This is complete disinformation. Microsoft gives you the OPT-IN OPTION to save your Bitlocker encryption key to your account.
It's clearly labeled and you need to click on it to activate it:
https://allthings.how/content/images/wordpress/2021/11/allth...
The datacenter use case sounds useful—should have led with that.
My problem with the piece is that it reads like the usual knee-jerk pro-Linux FUD that typically originates around scare words like "Microsoft", "secure boot" and "UEFI".
That's not zero. In my mind that's the main thing a TPM is really useful for. It's a secure enclave for a private key used for U2F/WebAuthn style attestation. I agree that the threat model not being explicitly discussed is a huge miss. But to that point, a TPM is still useful because it prevents someone who has hacked into my computer from commanding the TPM's authentication factor.
The other useful application is to prevent block device data extraction without knowing the passkey. And the author's argument there hinges on the notion that Microsoft won't patch OS security vulnerabilities that enable key extraction from memory. Which, OK, third-party drivers suck, but Microsoft's effort to patch is also not zero, and the most common (OS+browser/sandbox) threat model requires a chain of vulnerabilities that are hard to come by.
How?
Actually, on second thought, it's secure boot that protects against this attack, which doesn't require or use a TPM? So maybe I'm wrong
Even then, the argument that a TPM is worthless because it can't guarantee that software is free of vulnerabilities just belies an un-seriousness of the post. Like okay, that argument applies to every threat model ever.
A boot chain can be secure with or without a TPM. The TPM just says "I'll record what your boot chain told me and spit it back out with a signature that is verifiable by public key cryptography, so that you can tell it's what your boot chain told me. How much you trust your boot chain is up to you."
(Most other threat models go "ok we trust some part of this is secure, and that means we can guarantee x, y, z; if that part is not secure then we cannot do this.)
> Each of dozens (up to hundreds) of UEFI drivers written by various OEMs with varying levels of competence and care are loaded
Doesn't the BIOS signature encompass those drivers? Put another way, isn't the BIOS vendor attesting those drivers are non-malicious with their signature?
I think the TPM will turn out to be a net negative for consumers since it's going to get used to get used for attestations users can't control (ie: against the will of the user), but there are some benefits. Having a BitLocker key unlocked via a PIN where the TPM can protect against brute force attacks is useful for me. That alone covers most of my threat model which is having my data extracted from a lost or stolen PC.
D-RTM requires TPM.
That means it either requires a second protocol for authentication, or that you will lose your accounts with all kinds of services all the time.
There are plenty of valid use-cases where you'd want the machine to authenticate itself to services (VPN to enterprise network?) before anyone logs in (or ever logs in, as in the case of servers who operate unattended).
This one is huge: always-on VPNs mean enterprise security mandates don’t delay patching or other remote management tasks just because someone is on vacation or sick, and that stuff can happen at 3am on Sunday rather than when they start work. No more “please leave your computer on overnight” messages.
So for example, if I login to Gitlab on my phone, I can use my fingerprint (lockscreen auth). It's more convenient than using the TOTP app.
Similarly, I could register a TPM from my desktop that could be the same as using the fingerprint auth? It would only work from that desktop, but it's the same logic as my phone, and in a sense, that's a nice benefit.
Sometimes I think the average person would be better of with a highly secured email account and magic links for everything else. Even for me, I have YubiKeys, TPMs, etc. configured for everything, but if I forget to lock my laptop and someone walks off with it, they have access to my email which is basically my entire digital life due to account recovery via email.
Technically speaking, the exact same restrictions apply to a Yubikey.
That’s what makes it secure.
EDIT: To clarify, Widevine doesn't actually use the TPM, but Widevine L2 uses a TEE for key exchange and decryption, which are all things that modern TPMs support. The use a crypto coprocessor for key exchange and decryption is widely used.
Time to go back to kernel mode everything I guess. Just run everything as root, get rid of sudo.
> There are a plethora of attacks on TPM in the past but we need to be clear that a system that is widely attacked does not necessarily mean it is fundamentally insecure but only that there are many implementation issues. Most of these implementation issues do not touch upon the points raised in this article (it doesn't matter if the gate to your garden is strong or weak if there is no fence around the garden). Nevertheless, many of the attacks demonstrate the lack of care and consideration in the TPM ecosystem.
The issue is that TPM is being heavily pushed while it provides no security value. When you have Secure Boot (no additional hardware required), you get everything that Microsoft promises. The entire idea of TPM is that it gives you an extra level of security and I argue that it doesn't.
TPMs can do other useful things besides performing attestation measurements for trusted computing, including acting as a secure element to safeguard and rate-limit keys used for SSH, disk encryption and much more.
Good luck trying to remote (RDP) into a Windows box with a passwordless account or to access a fileshare.
While passwordless Microsoft accounts are very convenient it is only according to MS Marketing department that windows can be a true passwordless system. In reality it is not. There any several components in Windows that does not work with a passwordless account. The RDP and network issues has been know for many years and is a PITA for home networking.
I do have a travel laptop and recently installed LUKS to it. I like having my long password, but being able to tie unlocking to the hardware sounds like a good idea too. Is there a way to have both? A long password and require the local TPM?
Despite the shortcomings, I think they are very useful devices from the perspective of running data centers. I consider it useless against evil maid attacks though.
Nowadays with Microsoft making it a requirement (as well as fTPM which means the TPM no longer requires dedicated hardware) we might see more use-cases.
I'd have to check if bottom cover tampering on my Lenovo actually requires me to put in the BitLocker keys again.
No dang, I don't care about the spirit of the site when absolute ludicrous mindrot garbage is up voted here constantly. You'll note on the Wayland thread that, despite being the 30th Wayland thread, the only substantive reply agreed with me. It's a joke.
Don't worry, I'm changing my password to a random guid, you'll be free of me in 45 seconds.
TPM is the specification and standard for a predictable way this is implemented, and most modern CPUs do this as you say, with option ROM validation, UEFI firmware integrity checking, etc.
> Note that at any point in this process, if the attacker is able to control code execution, there is no way for TPM to know that the measurement it was just handed wasn't a lie. Now let's assume you are an attacker trying to get the BitLocker keys, what can you do? [0]
[0] https://gist.github.com/osy/45e612345376a65c56d0678834535166...
> The other useful application is to prevent block device data extraction without knowing the passkey.
Nope, read the appendix. Since 2006, BitLocker without PIN is vulnerable to physical extraction with $80 worth of equipment. And to enable enhanced PIN for BitLocker you have to jump to a lot of hoops that most people don't even know about.
So some industry stakeholders are doing bad things with an inherently neutral technology. Does that mean we need to get rid of the entire thing, thereby also killing the OSS use cases?
Yes, trusted computing can be used in user-hostile ways, but the solution here seems to be to not use OSes and applications using it in that way, rather than throwing out the technology as a whole.
Unfortunately, it's not much good for that either.
A yubikey has a button to confirm the user's presence - so even if a remote attacker has completely compromised the machine, because they can't press the button, they can't get anything out of the key.
The TPM has no button, so it has to rely on the OS to keep your pin safe from keyloggers. If your OS is that trustworthy, you might as well just store your secrets in the OS keyring.
The TPM is also about 50x more complicated than a yubikey, to support things like multi-user systems. This means there's a much bigger attack surface.
And it’s not like those “scare words” didn’t become scary for a reason. Your response starts with reverse FUD.
The early bypass of widewine meant burning an nvidia shield (invalidating its keys) for each and every single rip.
You need something else (like Apple's FairPlay or Microsoft PlayReady) beyond that, and these definitely check your HDCP version. I believe 4k output commonly requires HDCP 2.2.
FairPlay on macOS might be based on obfuscation still (there was an interesting article on that here some days ago), but high-resolution playback on Windows definitely does involve the GPU driver somehow.
Do you have any references to back that statement up? Software-only DRMs are ultimately always either plain obfuscation or some variant of white-box cryptography, which is also anything but proven to actually work.
I’d really like Apple’s model on my machine where the root image is just the stock OS image unencrypted and the co-processor owns the responsibility of managing IO (and done efficiently) using my master key. TPM seems like it misses the mark from that perspective.
I thought Widevine on computers (whether Windows, macOS or Linux) is always L3, i.e. software only, and L1 needs a TEE on Android or an embedded OS such as on a set top box or streaming dongle.
A TEE can run "trusted" logic, such as DRM decryption code, and you can use a TPM-like device to hold the attestation keys and measurement funcitonalities for the TEE. I'm saying "TPM-like" because some TEEs have their own proprietary or embedded secure elements and don't need a TPM proper. (I'm actually not sure if TPMs are "TEE-aware", which would be required to e.g. only let some keys be used from the secure context, as otherwise storing DRM keys in the generally-accessible portion defeats the purpose.)
Without a TEE (and a TPM itself does not imply one on x86), what you can do is declare your entire system a TEE, and then use the TPMs measurements as an assertion over that system's untampered state.
This is pretty infeasible to do securely though, given the size of the codebase of most OSes, which is why the "DRM in TEE" approach is much more common. That's what Android does, for example.
And the default way of mitigating it is an even worse security risk. Now all your data is on some cloud somewhere, waiting for that vendor to get breached or your account to get phished which is now possible without physical control over your device. Plus, if you couldn't get into your computer because you lost access to your account, you also lost access to the data in the cloud.
Whereas if you really do have sensitive data, you still don't need a TPM and get better security without one. You keep a Yubikey in your pocket or memorize a strong passphrase and then the key physically isn't stored on your device.
But it's also their copy of all their bank statements that include their routing number, which nobody who is physically in their house is going to use against them but is a serious fraud risk if it can be accessed remotely on some cloud.
Something that works like a hardware security module, where it stores your keys and tries to restrict who can access them, has some potential uses. The keys are only in your own device, so someone can't break an entirely different device or a centralized single point of failure to get access. And this can't be used against the user because both the device and the key itself are still fully in their control -- they could put a key in the HSM and still have a copy of it somewhere else to use however they like.
Whereas anything that comes with a vendor's keys installed in it from the factory is both malicious and snake oil. Malicious because it causes the user's device to defect against them and some users aren't sophisticated enough to understand this or bypass it even if malicious attackers can, and snake oil because you can't rely on something for actual security if a break of any device by anyone anywhere could forge attestations, since that is extremely likely to happen and has a long history of doing so.
I don't agree that all trusted computing use cases are inherently user-hostile. DRM is a well-known example, but e.g. Signal used to do interesting things server-side using (now no-longer trusted, ironically) Intel SGX/TXT, like secure contact matching or short PIN/password security stretching for account recovery.
Android Protected Confirmation [1] is also trusted computing at its core, but can be used to increase security for users (although I could also see that usage encourage a device vendor monoculture, since every app vendor needs to select a set of trusted device manufacturers).
> snake oil because you can't rely on something for actual security if a break of any device by anyone anywhere could forge attestations
Attestation keys are usually per-device, so if indeed only one device gets compromised at great attacker expense, it's usually possible for a scheme to recover. If all devices just systematically leak their keys as has certainly happened in the past, that won't help, of course.
[1] https://android-developers.googleblog.com/2018/10/android-pr...
Because this is the "snake oil" prong of its failure -- and why it's no longer trusted.
> Android Protected Confirmation
This could be implemented without any vendor keys. You associate the user's own key with the user's account.
> Attestation keys are usually per-device, so if indeed only one device gets compromised at great attacker expense, it's usually possible for a scheme to recover.
That's assuming it matters at that point. The attacker doesn't care if you revoke the keys after they steal your money.
And once they extract a key from one device, they have a known working procedure to get more. For non-software extraction most of the expense is the equipment which they'd still have from the first one.
> If all devices just systematically leak their keys as has certainly happened in the past, that won't help, of course.
And is likely to happen in the future, so any design that makes the assumption that it will not happen is clearly flawed.
This achieves two things: I know that I am typing my password into the OS that I or a trusted third party compiled (not one planted by a hacker), and my home directory gets decrypted as part of my normal login routine.
Yes, if the NSA has a decent reason to think you're going to nuke a sports game you'll still have a problem with very, very good security measures.
That doesn't mean there isn't a very large in-between zone where you're fine with better security measures.
Yes, with Secure Boot and password your data is safe. But you have to type the password to boot your system, which is impractical for remote and headless systems, or even local systems that need to be available remotely.
But how would you bootstrap this? How do you make sure the initial key was actually created in the secure exceution environment and not created by MITM malware running on the main application processor?
If this was that easy, FIDO authenticators wouldn't need attestation either.
> That's assuming it matters at that point. The attacker doesn't care if you revoke the keys after they steal your money.
If attacking a single device costs a few millions, it definitely does matter, since you'd need to expend that effort every single time (and you'd be racing against time, since the legitimate owner of the device can always report it as stolen and have it revoked for transaction confirmation, transfer their funds to another wallet etc.)
> And is likely to happen in the future, so any design that makes the assumption that it will not happen is clearly flawed.
How does some implementations falling apart imply all possible implementations being insecure? Smartcards are an application of trusted computing too, and there have been no successful breaches there to my knowledge. The fact that the manufacturers specialize in security, not in general-purpose computing like Intel and only occasionally dabble in security, probably helps.
The device comes with no keys in it, but includes firmware that will generate a new key, put it in the HSM and provide the corresponding public key. The public key is authenticated to the service using whatever means is used to authenticate the user rather than the device, because what you're doing here is assigning the key in this device to this user, so it's the user and not the device you need to authenticate.
But now if the user wants to they can use a different kind of device.
> If this was that easy, FIDO authenticators wouldn't need attestation either.
They shouldn't.
> If attacking a single device costs a few millions, it definitely does matter, since you'd need to expend that effort every single time (and you'd be racing against time, since the legitimate owner of the device can always report it as stolen and have it revoked for transaction confirmation, transfer their funds to another wallet etc.)
You're talking about the HSM case where the user's own key is in the device and you need to break that specific device. In that case you don't need to prove that the device is a specific kind of device from a specific manufacturer (remote attestation), you need to prove that it is that user's device regardless of what kind it is (user's key in the HSM).
> How does some implementations falling apart imply all possible implementations being insecure?
Because for remote attestation the attacker can choose which device they use for the attack, so if there is any insecure implementation the attacker can use that one.
And if you deploy a system relying on it and then a vulnerability is discovered in millions of devices you're screwed, because you now have a security hole you can't close or you have to permanently disable all of those devices and have millions of angry users. But this is historically what has happened, so relying on it not happening again is foolish.
> Smartcards are an application of trusted computing too, and there have been no successful breaches there to my knowledge.
Smartcards don't require any kind of a third party central authority. You know this is Bob's card because Bob was standing there holding it in his hand while you scanned it and assigned it to Bob in the system. Bob could have made his own card and generated his own key and it works just as well. It's a completely different thing than remote attestation.
