This is my interpretation of a trustworthy computing model --> [i only quickly wrote this up tonight, and havent reviewd it - i'll work on it later in terms of revision etc] Silvio Cesare ---- CONTENT SERVICE PROVIDING TRUST SECURE HOST ESTABLISHMENT BOOT TIME INTERROGATION HARDWARE INTEROGATION SOFTWARE INTEROGATION RUNTIME INTEROGATION PROVIDER/CLIENT TRUST ESTABLISHMENT TRUST SECURITY ENCRYPTION TCPA SECURITY ATTACKS CLIENT ATTACKS TRUSTED SOFTWARE ATTACKS REPLAY ATTACKS HARDWARE ATTACKS PROVIDER IMPERSONATION ATTACKS MAN IN THE MIDDLE ATTACKS PROVIDER ATTACKS PROVIDER IMPLEMENTATION ATTACKS PROVIDER HOSTING ATTACKS CONTENT ENCRYPTION SESSION ENCRYPTION ATTACKS SESSION KEY PREDICITION ATTACKS SESSION KEY DISCLOSURE ATTACKS CONTENT STORAGE DISK ENCRYPTION OPERATING SYSTEM ENCRYPTION CPU ENCRYPTION DEVICE ENCRYPTION PC [DISK + CPU] IDENTITY SYNCHRONIZATION MASTER KEY DISK ACCESS ATTACKS LIVE ATTACKS HARDWARE SNOOPING SOFTWARE OPERATING SYSTEM ENCRYPTION CONTENT PROVIDER VERIFICATION [REVISITED] TELECOMMUNICATIONS DIALUP INTERNET SERVICE PROVIDER ATTACKS EFTPOS ATTACKS CONTENT SERVICE PROVIDING ------------------------- SECURE HOST ESTABLISHMENT ------------------------- BOOT TIME INTERROGATION ----------------------- During bootup, the CPU (fritz etc) interrogates your software and hardware to determine the current configuration. It will determine what software and hardware is present on the system, and if these systems are trusted or non trusted. HARDWARE INTEROGATION --------------------- The cpu maye probe available devices, for which the hardware will provide its identity or registration in a secure method to defeat eavesdropping through software methods. In one scenario, the CPU could send its public key (pc identity) to the hardware devies. The hardware will then encrypt its own identity with the public key of the pc and send it back across the bus. The cpu then has the ability to identify the hardware using its own private key for decryption. Eaves dropping bus transfers does not reveal such information; the bus transfers are encrypted using asymetric cryptography. If this is done in pure hardware, then software eavesdropping does not reveal confidential information that will allow the private keys or registration identity to be disclosed, given the security of the cryptography being used. Most likely, this will be an RSA implementation as indicated by the Fritz CPU by INTEL. The CPU may then store the list of identities provided by the hardware devices for later interogation by your provider implementing its own Digital Rights Management (DRM) policies. SOFTWARE INTEROGATION --------------------- A likely scenario is to verify in a rudimentary manner that the host OS has not been tampered with in a manner that is in violation of the trustworthy computing model. The cpu may make an integrity verification on initial boot software. The primary bootblock may be verified as being trusted and non tampered. This may be useful for some class of virus - not typically seen in current times, and dates back to AV technology during the DOS era). The kernel image may also be verified as being trusted and non tampered, providing a reasonably clean low-level bootup providing the hardware is also trusted. A simple implementation of kernel image verification is to provide the cpu with a memory region to be verified as trusted. The primary bootblock may be implemented in the disk device itself to verify trust. The boot device however must be previously identified as being trusted for the trust relation to provide security. RUNTIME INTEROGATION -------------------- If the hardware, and initial boot is trusted, then the host OS may also be extended to verify trust of the applications it runs. The applications may make a request to the kernel to allow the program to continue execution via a DRM policy. This would be used in software such as playing a providers streaming content - DVD/MP3 etc. If the application is trusted by the provider, then it will be known to have strict functional constraints. It will not be a program to copy content or violate copyrights of the providers content. PROVIDER/CLIENT TRUST ESTABLISHMENT ----------------------------------- An application on the clients computer may request a service for streaming content of a provider. The provider may then interogate the client to establish a trust relationship. It may send its own public key so that the client will later use it to encrypt the negotiation. The application on receiving an interrogation query may then ask the CPU to provide an identity. The application will send the public key of the provider to the CPU. The CPU will then use this public key to encrypt the configuration of the hardware and software. It may then return this information in encrypted format back to the application. Eavesdropping at the software level does not reveal the identity of the configuration unless the providers private key is known or the cryptography is flawed. The application can then transmit this encrypted content giving the identity of the computer back to the provider. The provider may then decide its policy on allowing the service. Because the application and the computer identities are given to the provider - the provider may determine its policy on allowing the service to the client. If the application requesting the service is not trusted (ie, it does not maintain the requirements of non copyright violation or possible copyright violation), then the provider can deny the service. TRUST SECURITY -------------- This system of trustworthy computing provides security against software eavesdropping, and eavesdropping between devices. The identities, keys and confidential information are encrypted for all communication. If the software or hardware is not trusted, then policy decisions may be made by the provider to allow or deny service. ---------------------------- ENCRYPTION ---------- The CPU may store a list of keys/identities. It also maintains its own unique private and public key pair. CPU interogates DEVICE CPU -> DEVICE [K: cpu public key] DEVICE -> CPU [C: encrypt(K, device identity)] CPU decrypt(C, private key) revealing device identity store device identity in CPU Application/Provider trust establishment [modified version for defense against replay attack later] Application -> Provider [Request for service] Provider -> Application [Request for identity] [K: public key of provider] Application -> OS [request provider service] [K] OS -> CPU [request software trust] [K] [D: digest of application software] CPU -> OS [reply software trust] [A: encrypt(K, device configuration + D)] OS -> Application [reply software trust] [A] Application -> Provider [reply provider service] [A] Provider Identity = decrypt(private key, A) policy(Identity) accept/reject Provider -> Application [accept/reject] At all times, communication is encrypted, and does not allow eavesdropping, yet still provides the ability for the provider to have a strict per pc or software policy. TCPA SECURITY ------------- The model presented does addresses trust establishment, it does not fully address DRM security in the strict sense. The model does provide secure trust relationshipts to be established. It does not provide security assurance of software or hardware - it only states if they are trusted. If software or hardware is not "verified" as being secure, then the security policy of the client may violate the provider policy. If software or hardware is non secure, and through vulnerability allow functiionality violating the DRM policy, then the DRM is vulnerable. The implementation may also be vulnerable to cryptographic attacks - even reply attacks may be effective in some circumstances. ATTACKS ------- CLIENT ATTACKS -------------- TRUSTED SOFTWARE ATTACKS ------------------------ Trusted software does not define secure software. If the operating system or programs within, are vulnerable to exploitation through any manner and are of priveledge, then the above model is open to attack. 1) Through an implementation bug in the trusted software, extra functionality may be added to the host in violation of the end user DRM policy. Through an OS implementation bug, the OS may be modified at runtime to divert streaming content. It may divert this content for the purposes of copying data, in likely violation of a providers DRM policy. Unless all programs are verified secure that have the capability of modifying the OS or trusted software, then trusted software is not verified as being secure software [to use a definition as a definition]. In all current software, security assurance has never come to fruition and is likely not too in the forseeable future. Even the JVM sandbox has been found flawed. So to the kernels for the majority of operating systems. In conjunction it is unlikely that the application being trusted is implemented securely. In my belief, this presents a likely attack that will succeed against TCPA and defeat future DRM. It is likely that to combat this, more functionality will be moved from software into hardware such as MPG and MP3 players etc. REPLAY ATTACKS -------------- 2) Replay attacks may allow for the "stealing" of identities. It is likely that content providers will take this into account and attempt to defeat this attack through a modification to the cryptographic system --> Provider -> Application [Request for identity] [K: public key of provider] [F: encrypt(private key of provider, time stamp/magic)] ... OS -> CPU [request software trust] [K] [F] [D: digest of application software] CPU -> OS [reply software trust] [A: encrypt(K, F + device configuration + D)] This will allow the provider to protect against a typical replay attack. HARDWARE ATTACKS ---------------- If the CPU or hardware devices are compromised in terms of information disclosure, then identities can be cloned. It would be similar to hardware SIMM card cloning. Provider revokation of services through policies would be used to stop this once it is known that an identity has been cloned. PROVIDER IMPERSONATION ATTACKS ------------------------------ MAN IN THE MIDDLE ATTACKS ------------------------- If the end user cannot at runtime verify the identity of the content provider in a secure manner, then the identity of the end user will be revealed through provide impersonation. This will lead into identity cloning. A man in the middle attacks is extremely likely where the provider service requested by an end user is redirected to an imposter. The private client identity is now fully disclosed to the attacker. This is a very likely attack to be used, and has been seen already in a number of cases, through DNS and SSL for most applications and services. Revokation by the provider is again the solution to be used once it is known that the identity has been cloned. PROVIDER ATTACKS ---------------- PROVIDER IMPLEMENTATION ATTACKS ------------------------------- If a pre authentication bug is seen in the content providers TCPA implemenation, then much is probably possible. OpenSSH has seen problems like this in the past, as have nearly all other protocol implementations. PROVIDER HOSTING ATTACKS ------------------------ It is likely that the content prodivers will be attacked directly - it is unlikely that they will have a zero security compromise record. If policy databases are compromised, then alot is possible and havok will reak. If CC databases are anything to go by, I'm skeptical of TCPA. If the private keys are compromised, then TCPA is over. CONTENT ENCRYPTION ------------------ If the providers policy allows the client to use their content service, any content will be encrypted to avoid eavesdropping, likely in violatation of the DRM policy. SESSION ENCRYPTION ------------------ The provider or client may generate a session key for the content to be symmetrically encrypted. The key transfer can take place using the public keys that are known of both the client and provider. It is typical for the provider to create the session key. The provider creates a random session key, and then encrypts this using the known public key of the client. The client, then is able to decrypt content of the provider. Provider generates session key (A) Provider -> Application [notify] C: client public key [encrypt(C, A)] The trusted application can now decrypt any content by their provider. ATTACKS ------- SESSION KEY PREDICITION ATTACKS ------------------------------- If the session key can be predicted by an eavesdropper, then the symmetrically encrypted data can be decrypted. This is in likely violation of the DRM policy allowing the content to be stored offline and probably violating the copyright policy intended to be held by the TCPA model. SESSION KEY DISCLOSURE ATTACKS ---------------------------- If the host OS or trusted software is vulnerable to exploitation where the session key is revealed, then the encrypted content can be decrypted back to plaintext. If the host software contains security bugs allowing the disclosure of memory, and the session decryption is performed by the host OS or trusted software, then the session key can be disclosed. This is a likely attack that will defeat a DRM policy. The linux kernel for example has seen many forms of memory disclosure bugs, which would reveal session keys in a TCPA context. Likewise for FreeBSD, NetBSD and OpenBSD. CONTENT STORAGE --------------- DISK ENCRYPTION --------------- [ i added this a minute ago, and i've prolly done some typo's on the crypto algorithms etc.. will check later ] ** Although I use private key terminology for the CPU key in ** relation to stored disk contents, a symmetric key is likely to be ** the actual key. ** ENCRYPTED CONTENTS ------------------ A disk may be encrypted through this trustworthy system, so that the end-user must use a trusted system to read or write. The end-user cannot view the disk without their trusted system, nor can the contents be viewed elsewhere. OPERATING SYSTEM ENCRYPTION --------------------------- This cryptographic system is well known. The host OS keeps the private key in memory, and performs encryption before transfering the ciphertext to the storage device. CPU ENCRYPTION -------------- Given a "trusted" operating system software, the OS may make a request to the CPU for a memory region to be encrypted before transfer to storage. OS -> CPU [request] [memory region] CPU silently encrypt using private key of CPU CPU -> OS [ack] OS -> DISK [request] [store crypted memory region] This will reduce the performance of the system since the CPU is directly involved. It may however be in close co-operation with crypto hardware to alleviate this bottleneck. The CPU must not disclosue the private key used to encrypt the memory region. DEVICE ENCRYPTION ----------------- This system uses encryption within the device itself, but has plaintext bus transfers of the data. The disk devices gives the CPU its own public key. The CPU encrypts its private key with the public key from the disk. For all disk reads or writes, the contents are encrypted or decrypted using the confidential symmetric CPU key. If the disk is moved to another PC, its contents cannot be decrypted since the CPU has a different [unique] private key. Disk device in a known trusted state on a trusted system OS -> CPU [request] CPU -> Disk [request] [P: public key of CPU] [M: encrypt(P, magic1) Disk -> CPU [ack] D: public key of disk [E: encrypt(P, D + M)] [A: encrypt(D, magic2)] CPU decrypt(E) giving D + M verify magic1 CPU -> Disk [ack] S: private key of CPU [B: encrypt(D, S + A] Disk decrypt B revealing S + A decrypt(A) and verify magic2 At the discretion of the CPU or OS all furthur data to the disk, or encrypted by the disk, will now be stored as ciphertext using the CPU private key. PC [DISK + CPU] IDENTITY ------------------------ The private key of the CPU may be encrypted and stored on the disk in a known location. It may then be possible to match a disk/cpu pair as the identity of the PC. OS -> CPU [request] CPU -> OS [ack] [P: public key of CPU] [M: encrypt(P, magic) OS -> Disk [request disk pair identity] [P] [M] Disk -> OS [reply disk pair identity] [D: encrypt(P, sector of disk storing crypted identity + M] OS -> CPU [request] [D] CPU decrypt(D) giving sector + M decrypt M giving magic verify magic verify crypted identity == private key of CPU It is now known wether the disk and cpu provide the cofirmed and expected identity pair of the devices to fully identity the pc. The CPU must not disclose the private key at all to the operating system or any other communication channels. SYNCHRONIZATION -------------- If a new disk is introduced to a CPU, then the disk must synchronize to maintain a complete identity. If the identity verification fails, the disk can be identitified as having non "secure" contents. It may then be up to the OS and policy to determine if the disk should be retagged. Given a trusted host and non secure contents. OS -> CPU [request sync] CPU -> OS [ack] [P: public key of CPU] OS -> Disk [request sync] [P] Disk -> OS [ack] [D: public key of disk] [M: encrypt(P, magic)] OS -> CPU [request store private key] [D] [M] CPU -> OS [ack] S: private key of CPU [E: encrypt(D, S + M] OS -> Disk [ack] [E] Disk decrypt(E) giving S + M decrypt(M) and verify magic is the same encrypt(P, S) store MASTER KEY DISK ACCESS ---------------------- If a master public key is known to each PC, it may use this key to encrypt the private key of the CPU, and store these contents on disk in a known location. It is now possible for master access to the disk, if the private key of the master key pair is known. OS -> CPU [request public key] CPU -> OS [P: public key of CPU] [M: encrypt(P, magic1) OS -> Disk [request] [P] [M] Disk -> OS [ack] [K: public key of disk] B = encrypt(K, magic2) [D: encrypt(P, B + M)] OS -> CPU [request] [K] [D] CPU decrypt(D) to give B + M decrypt(M) and verify magic1 CPU -> OS [request] S: master public key X = encrypt(S, private key of CPU) [A: encrypt(K, X + B] OS -> Disk [request] [A] Disk decrypt(A) to give X + B decrypt(B) and verify magic2 store X at known position on disk ATTACKS ------- LIVE ATTACKS ------------ HARDWARE SNOOPING ----------------- The data transfers across the bus may be in plaintext if the device is employing the cryptographic process. In this case bus snooping may be possible in passive hardware. This type of attack is unlikely for all but some devices. SOFTWARE -------- The software may be exploited for expanded functionality, the contents of the disk perused through the trusted software. The vulnerability exploited in software may then redirect these contents to off-line plaintext storage. This is a likely attack that will be employed to defeat cryptographiclly secured storage when the system is online. OPERATING SYSTEM ENCRYPTION --------------------------- In the scenario when disks are encrypted and tied to the CPU via keys, and the OS is performing the associated content encryption before storage by the disk device, the private key is available in the operating system internals. If the operating system is compromised, the private key can be retreived from memory. If the private key is never disclosed outside the CPU, then software snooping is defended against. CONTENT PROVIDER VERIFICATION [REVISITED] ----------------------------------------- If a master key is stored in the CPU for the purposes of master access to encrypted disk contents, then it may also be used for verifiying the identity of a content provider. In this scheme, the man in the middle attack used to impersonate a content provider and revelaing information is defended against. This also makes the trust establishment able to defeat through software methods, abilities to determine your unique pc identity, since this is no longer accessible unless you are verified as a content provider. This still however does not stop the circumvention of DRM using other attacks. The master key usage for content provider verification would be primiarly used for content provider verification, or master access to your pc. TELECOMMUNICATIONS ------------------ DIALUP INTERNET SERVICE PROVIDER ATTACKS ---------------------------------------- It is uncommon for a client of an Internet Service Provider (ISP) to verify their provider. If a man in the middle attack occurs where the telephone call is rerouted to an attacker, the provider can be impersonated. In this scenario, it is unlikely to receive a plaintext password upon initial connection negotation. If a challenge response authentication system is used, eg CHAP, PAP, the shared secret is not transmitted in plaintext across the communication channel. It is likely though, that once a connection has been authorized, which typically requires only the providers acknowledgement, the shared secret may be revelead elsewhere. An example of this disclosure, is through retrieiving stored mail, such as using POP. If the ISP uses an encrypted channel where the shared secret is revealed, unless the client verifies the identity of their provider, an attacker can impersonate them, thus also obtain the shared secret. An example of this is using a mail service over SSL. This type of attack has to my knowledge, never been reported. EFTPOS ATTACKS -------------- [ can someone give me the specs on this? or do i have to guess? ] It is likely that an EFTPOS link is an encrypted peer to peer communication channel that uses the initial connection negotiation to manage a session key for encryption of the session. It may also renegotiate a new session key at regular intervals, if the link is active for a long period of time. The EFTPOS appliance may hold a private key as an identitifcation token. During initial session negotiation, the provider can identity the appliance without the private key being disclosed across a nontrusted communication channel. The provider once establishing the identity of the appliance, and authorizing use of the service through policy, may establish a session key for session encryption. Eavesdropping the communication channel should not reveal confidential information, as the session is encrypted, and the session negotiation is verifies identity. A possible EFTPOS attack, where the EFTPOS appliance did not verify the identity of its provider, a man in the middle attack may be used for provider impersonation during session negotiation and future transanactions. This negotitation is likely to occur at startup time, and after link failure. In the same situation as rerouting the telephone call to an ISP, if the EFTPOS provider, requires only to consent that the EFTPOS transaction is authorized, the EFTPOS appliance may also be subject to a man in the middle attack. Through impersonation of their provider, the appliance may falsely believe that later transactions have been verified against the account balance and other necessary details, via authorization of the impersonated provider. It may also be possible for the attack to act as a router, between the client and provider, eavesdropping the encrypted session and transactions. Two encrypted sessions in this scenario would exist; one between client and attacker, and one between attacker and provider. If the above attack is possible, then EFTPOS card pin numbers may be disclosed from transactions, along with other information necessary for a transaction to be authorized. It may then be possible with that information to construct EFTPOS cards without the original card being physically available. This is in direct reference to magnetic strip cards. These types of attack have to my knowledge, never been reported. -- Silvio Cesare