Editing Trusted Computing (section)

==Key concepts==
Trusted Computing encompasses six key technology concepts, of which all are required for a fully Trusted system, that is, a system compliant to the TCG specifications:
# Endorsement key
# Secure input and output
# Memory curtaining / protected execution
# Sealed storage
# Remote attestation
# Trusted Third Party (TTP)

==={{anchor|ENDORSEMENT-KEY}}Endorsement key===
The endorsement key is a 2048-bit [[RSA (algorithm)|RSA]] public and private key pair that is created randomly on the chip at manufacture time and cannot be changed. The private key never leaves the chip, while the public key is used for attestation and for encryption of sensitive data sent to the chip, as occurs during the TPM_TakeOwnership command.<ref>{{cite web | author = Safford, David | url = http://www.linuxjournal.com/article/6633 | title = Take Control of TCPA | date = 2003-08-01 | access-date = 2007-02-07 | work = Linux Journal | author-link = David Safford }}</ref>

This key is used to allow the execution of secure transactions: every Trusted Platform Module (TPM) is required to be able to sign a random number (in order to allow the owner to show that he has a genuine trusted computer), using a particular protocol created by the Trusted Computing Group (the [[direct anonymous attestation]] protocol) in order to ensure its compliance of the TCG standard and to prove its identity; this makes it impossible for a software TPM emulator with an untrusted endorsement key (for example, a self-generated one) to start a secure transaction with a trusted entity. The TPM should be{{vague|date=March 2015}} designed to make the extraction of this key by hardware analysis hard, but [[tamper resistance]] is not a strong requirement.

===Memory curtaining===
Memory curtaining extends common [[memory protection]] techniques to provide full isolation of sensitive areas of memory—for example, locations containing cryptographic keys. Even the [[operating system]] does not have full access to curtained memory. The exact implementation details are vendor specific.

==={{anchor|SEALED-STORAGE}}Sealed storage===
Sealed storage protects private information by binding it to platform configuration information including the software and hardware being used. This means the data can be released only to a particular combination of software and hardware. Sealed storage can be used for DRM enforcing. For example, users who keep a song on their computer that has not been licensed to be listened will not be able to play it. Currently, a user can locate the song, listen to it, and send it to someone else, play it in the software of their choice, or back it up (and in some cases, use circumvention software to decrypt it). Alternatively, the user may use software to modify the operating system's DRM routines to have it leak the song data once, say, a temporary license was acquired. Using sealed storage, the song is securely encrypted using a key bound to the trusted platform module so that only the unmodified and untampered music player on his or her computer can play it. In this DRM architecture, this might also prevent people from listening to the song after buying a new computer, or upgrading parts of their current one, except after explicit permission of the vendor of the song.

==={{anchor|REMOTE-ATTESTATION}}Remote attestation===<!-- This section is linked from [[Trusted Computing]] -->
Remote attestation allows changes to the user's computer to be detected by authorized parties. For example, software companies can identify unauthorized changes to software, including users modifying their software to circumvent commercial digital rights restrictions. It works by having the hardware generate a certificate stating what software is currently running. The computer can then present this certificate to a remote party to show that unaltered software is currently executing. Numerous remote attestation schemes have been proposed for various computer architectures, including Intel,<ref>{{cite book |last1=Johnson |first1=Simon |title=Intel Software Guard Extensions: EPID Provisioning and Attestation Services |date=2016 |publisher=Intel |url=https://software.intel.com/content/dam/develop/public/us/en/documents/ww10-2016-sgx-provisioning-and-attestation-final.pdf |access-date=14 May 2021}}</ref> RISC-V,<ref>{{cite conference |last1=Shepherd |first1=Carlton |last2=Markantonakis |first2=Konstantinos |last3=Jaloyan |first3=Georges-Axel| title=LIRA-V: Lightweight Remote Attestation for Constrained RISC-V Devices |date=2021 |conference=IEEE Security and Privacy Workshops |publisher=IEEE |arxiv=2102.08804 }}</ref> and ARM.<ref>{{cite conference |last1=Abera |first1=Tigist |title=C-FLAT: Control-Flow Attestation for Embedded Systems Software |series=CCS '16 |date=2016 |pages=743–754 |publisher=ACM |doi=10.1145/2976749.2978358 |isbn=9781450341394 |s2cid=14663076 |url=https://dl.acm.org/doi/abs/10.1145/2976749.2978358 |access-date=14 May 2021|url-access=subscription }}</ref>

Remote attestation is usually combined with public-key encryption so that the information sent can only be read by the programs that requested the attestation, and not by an eavesdropper.

To take the song example again, the user's music player software could send the song to other machines, but only if they could attest that they were running an authorized copy of the music player software. Combined with the other technologies, this provides a more restricted path for the music: encrypted I/O prevents the user from recording it as it is transmitted to the audio subsystem, memory locking prevents it from being dumped to regular disk files as it is being worked on, sealed storage curtails unauthorized access to it when saved to the hard drive, and remote attestation prevents unauthorized software from accessing the song even when it is used on other computers. To preserve the privacy of attestation responders, [[Direct Anonymous Attestation]] has been proposed as a solution, which uses a group signature scheme to prevent revealing the identity of individual signers.

[[Proof of space]] (PoS) have been proposed to be used for malware detection, by determining whether the L1 cache of a processor is empty (e.g., has enough space to evaluate the PoSpace routine without cache misses) or contains a routine that resisted being evicted.<ref name="JakobssonStewart13">{{cite conference |last1=Jakobsson|first1=Markus|last2=Stewart|first2=Guy|title=Mobile Malware: Why the Traditional AV Paradigm is Doomed, and How to Use Physics to Detect Undesirable Routines|conference=Black Hat USA|year=2013}}</ref><ref>Markus Jakobsson [https://eprint.iacr.org/2018/031.pdf Secure Remote Attestation] ''Cryptology ePrint Archive.'' Retrieved January 8, 2018.</ref>

===Trusted third party===
{{Main|Trusted third party}}