Announcement

Collapse
No announcement yet.

Intel Open-Sources New TPM2 Software Stack

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Paul K
    replied
    Originally posted by Slithery View Post
    Does anyone know if there are any other hardware providers? You could then choose to trust someone other than Intel.
    Hi,
    here you could find a buyable TPM 2.0, pin compatible to the RaspberryPi.


    Paul


    Disclaimer: I own the website LetsTrust.de and developed this board.
    PS: If I violated forum rules, please delete/correct this post.
    I just wanted to answer the question, thank you
    LetsTrust TPM (Trusted Platform Module), als Aufsteckmodul für den Raspberry Pi. True Hardware Random Number Generator (TRNG), Schlüssel-Speicher, Crypto-Apps.

    Leave a comment:


  • audir8
    replied
    Originally posted by starshipeleven View Post
    It's more convenient, yes, but it's not as secure. Security comes from having someone actually on watch and knowing and thinking about things.

    If someone pwnzored your servers you would never find out as all the "security" is automated.
    A logging TPM like most BIOS password logging I'm sure exists. Security is in having a secure network of trust, sure you need monitoring and logging, but if you can build a network of trust, you'll get pretty far even if it's only occasionally monitored instead of having to enter a password at every boot.

    Either getting a password through bribing and social engineering is hard, or getting it from hacking a TPM or UEFI is hard. You first mentioned the later is harder, then said it was not as secure.. come again? I'm pretty sure buying monitoring equipment from Amazon is easier and cheaper than hacking UEFI or a TPM if I really wanted to know the average person's password. 2FA is more secure, and the most secure version of it is an automatically generated number that you enter within a time period. Hardware hacking can be made harder if TPMs and UEFI/Linux authenticated each other with PKI. Malicious UEFI hacks would also go away if you did this and designed it well enough.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by audir8 View Post
    Let's get this in grub, sometime... yeah.
    You can add all you want in the initramfs, be it ssh or mail or whatever. You're still relying on SecureBoot to load Linux images from the boot partition (usually the UEFI partition) only if it is signed. Boot times on servers are so hideously long anyway, adding a few more seconds for an initramfs won't matter.
    https://unix.stackexchange.com/quest...-during-bootup

    And note that unless the server is isolated from the outside network even just ssh is enough, as we are in 21st century and any smartphone can have an ssh client (or server or whatever) and a VPN to the server's internal network.
    It literally takes less than 5 minutes to authorize the server.

    a datacenter has options.
    A datacenter (or any other company) does not really need security, it needs a scapegoat to not be blamed in case there are breaches.

    That's what TPM is. If TPM or UEFI fail and get hacked it's not their fault anymore.

    If I was making something secure for myself I'd not do that. On a company server who gives a shit. I obey orders to get paid, nothing more.

    Malicious UEFI or hardware hacking is a concern, but by that point you're so much better off than a a key on a USB stick to boot/reboot an unattended remote server.
    I disagree. I'm pretty sure that anyone who is really into getting your data and can't just do it the easy way (getting the password by bribing or threating admins or whoever has it) will be a bit upscale.

    If they can just go the easy way you still get a notification to all admin staff that the server asked for a password at X time and the mail system will log that X admin mail account answered it. With a TPM how can you know who and when did the hack?

    No DRM, no fuss.
    That's not why I mentioned DRM. I mentioned it because in consumer devices it is actually used to store license keys and other DRM paraphenalia. On servers it's a different story.

    As GKH's todo says from 5 years ago: "Combine signed kernel images with TPM key storage to unlock encrypted partitions." Which still sounds better than entering passwords to me.
    It's more convenient, yes, but it's not as secure. Security comes from having someone actually on watch and knowing and thinking about things.

    If someone pwnzored your servers you would never find out as all the "security" is automated.

    Leave a comment:


  • audir8
    replied
    Originally posted by starshipeleven View Post
    ...have the server itself shoot an e-mail to the admin staff to ask for the password before booting.
    Let's get this in grub, sometime... yeah. There isn't a consumer solution out there apart from TPMs or physically entering passwords, sure a datacenter has options.

    Malicious UEFI or hardware hacking is a concern, but by that point you're so much better off than a a key on a USB stick to boot/reboot an unattended remote server. I'll take me_cleaner to get rid of most of ME, TPM access from Linux for luks drives through open drivers, and UEFI can verify the image I'm booting using an all software solution: http://kroah.com/log/blog/2013/09/02...-linux-kernel/ No DRM, no fuss.

    As GKH's todo says from 5 years ago: "Combine signed kernel images with TPM key storage to unlock encrypted partitions." Which still sounds better than entering passwords to me.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by audir8 View Post
    If you want a remote server to boot from an encrypted drive, without a 3rd party being able to decrypt the drive when online or in another computer... Storing the luks key in a TPM is the only way to do this apart from netbooting, but then you have to secure the netboot server somehow. So you're back to TPMs.
    The main point here is that I don't trust TPMs to be really secure beyond basic garden-variety attackers, as the whole security model relies on SecureBoot, UEFI, sometimes the ME and all that.
    If someone pwns UEFI/ME you're fucked as they have access to the TPM keys. Some TPMs can be hacked if the attacker has hardware access https://online.tugraz.at/tug_online/...umentNr=203846 .

    I don't see the issue for servers. Just use a special secure (in the sense of physically tamper-proof hardware) server for the keys of all your datacenter, or even have the server itself shoot an e-mail to the admin staff to ask for the password before booting. In any half-decent facility you will have to have someone on watch or ready to respond from home anyway, and a server rebooting is usually an issue to be solved.

    The same level of stupidity is for laptops. It's not supposed to boot unattended, why it shouldn't ask ME the password?

    So what's the TPM there for? Convenience and to lock down consumer devices for DRM or other such stuff. No thanks, I can do without.

    Leave a comment:


  • audir8
    replied
    Originally posted by starshipeleven View Post
    If the device was using the ME for the TPM provider, you will lose the TPM if you neuter the ME. Because it's the ME that is the TPM in that system, there is no dedicated hardware.

    But anwyay, who cares about TPM.
    If you want a remote server to boot from an encrypted drive, without a 3rd party being able to decrypt the drive when online or in another computer... Storing the luks key in a TPM is the only way to do this apart from netbooting, but then you have to secure the netboot server somehow. So you're back to TPMs.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by audir8 View Post

    This is probably true for some OEM manufacturers, but as the me_cleaner README notes, with enough reverse engineering you can get some functionality back, or not lose any functionality after flashing. I've yet to try it on my machines, but I look forward to finding out how ASUS/Lenovo do things when I do.

    You can also get a TPM with coreboot in libre laptops: https://puri.sm/posts/tpm-addon-for-librem-laptops/
    If the device was using the ME for the TPM provider, you will lose the TPM if you neuter the ME. Because it's the ME that is the TPM in that system, there is no dedicated hardware.

    But anwyay, who cares about TPM.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by Espionage724 View Post
    I believe my Acer desktop uses Intel ME for the TPM. tpm.msc under Windows reported the TPM version to be the same version as the ME firmware (11.8.something), and upon using me_cleaner to set the HAP bit (gracefully disable Intel ME), the TPM could not be enabled again nor does the BIOS option reveal any options for it anymore.
    That's a "software TPM". It is the cheapest of the possible TPM systems, and imho the worst one from a security standpoint.

    Leave a comment:


  • audir8
    replied
    Originally posted by Espionage724 View Post

    I believe my Acer desktop uses Intel ME for the TPM. tpm.msc under Windows reported the TPM version to be the same version as the ME firmware (11.8.something), and upon using me_cleaner to set the HAP bit (gracefully disable Intel ME), the TPM could not be enabled again nor does the BIOS option reveal any options for it anymore.
    This is probably true for some OEM manufacturers, but as the me_cleaner README notes, with enough reverse engineering you can get some functionality back, or not lose any functionality after flashing. I've yet to try it on my machines, but I look forward to finding out how ASUS/Lenovo do things when I do.

    You can also get a TPM with coreboot in libre laptops: https://puri.sm/posts/tpm-addon-for-librem-laptops/

    Leave a comment:


  • Espionage724
    replied
    Originally posted by audir8 View Post

    The TPM spec is open, the drivers are open, it doesn't have access to main memory like Intel ME does AFAICT under any number of it's modes and possible design applications. https://trustedcomputinggroup.org/re...specification/

    It stores numbers securely, and either the BIOS or the OS (face/thumb print recognition etc..) can query these numbers given certain conditions. Secure key storage is a pretty old problem, If Atmel's TPM is insecure or has a backdoor, you can switch to others (giving Atmel enough reason to not do those things). These are basically the same guarantees you have with any peripheral connected to any I/O port on your computer. It's up to you if you want to store certain keys or not in a TPM, but I would say in most circumstances, it can make for an additional layer of security, that's just as importantly practical enough to use for the average user. I think they should be more widespread because of this.
    I believe my Acer desktop uses Intel ME for the TPM. tpm.msc under Windows reported the TPM version to be the same version as the ME firmware (11.8.something), and upon using me_cleaner to set the HAP bit (gracefully disable Intel ME), the TPM could not be enabled again nor does the BIOS option reveal any options for it anymore.

    Leave a comment:

Working...
X