WO2009109811A1

WO2009109811A1 - Platform security model for networking solution platforms

Info

Publication number: WO2009109811A1
Application number: PCT/IB2008/050834
Authority: WO
Inventors: Ashish Anand
Original assignee: Ashish Anand
Priority date: 2008-03-07
Filing date: 2008-03-07
Publication date: 2009-09-11

Abstract

Invention proposes a platform vendor premises located Provisioning server (002) as root-of-trust which also functions as image server for customers to enable them upgrading the image remotely as and when new release or patch is officially announced and provisions networking platforms with unique credentials at software, hardware and platform uniqueness level in a trusted manner, before customer shipment or whenever new release or patch is officially announced. To defeat tampering this invention enables the networking platform only to be operable with officially authorized images beyond any possibilities of data-theft by malicious insider. To defeat replication, every platform can be configured in master or slave mode (as shown in DIAGRAM 11 ) to function either as attestation unit or entity being attested. Platform can be switched to non-trusted mode of operation either locally through jomper setting on board or remotely through provisioning server such that a instrumented image can be run for debugging purpose whenever required.

Description

Description Platform security model for networking solution platforms

[1] The following specification describes the nature of this invention:-

[2] Technical field of invention

[3] This invention belongs to the field of application level cryptography combined with trusted computing and deals with attestation and certification of embedded networking platforms to make them tamper-proof and replication-proof such that secures network services like ipsec, ssl, anti- virus, intrusion detection, firewall can remain secured . It can be applied to many applications horizontally. It is illustrated in context of platforms used in enterprise edge networking solution, wireless mesh networking or surveillance application.

[4] Background:

[5] Conventional security on networking platform contains ipsec, ssl, intrusion detection, anti- virus, firewall module and similar other stuffs. Today data-security is extremely important module in such platforms. Above mentioned secured services protects enterprise data from outsider threat, but unfortunately there is no provision in any vendor platform to guarantee security of secured services itself. This invention targets the problem of possible security breach as result of platform- vendor insider conniving with customer site staff. A malicious insider can build a non- authorized image and connive with site-staff to load it on networking equipment. Damage to data-security caused by an un-authorized image can be irrecoverable. Some examples of damage caused by a un-authorized image is, Leaking common session key from IKE negotiation can be leaked and thus all security provided by ipsec/ssl vpn is lost, silently altering anti- virus signature database, opening access holes in firewall, or mirroring voice traffic to unintended ports and many such possibilities.

[6] Common practice is to provide hash based image authentication which provides no security for insider threat as security is rooted in software only. Similarly trust of role based authorization, authentication & accounting (AAA) again is only software rooted and can be easily breached by insider. This invention targets those kind of threats,

[7] 1. Which can be executed on platform itself and hence onus is on platform- vendor to solve this in totality.

2. Accountability is un-traceable even if detected

3. Those are executed in connivance with rogue vendor insiders with customer site staff and remain undetected,

4. Where Accountability is untraceable even after detection,

5. Where intrusion point located outside the perimeter of office and its physical security, facilitating sustained attack and hence threat situation becomes ad- equately practical. 6. Requires a technology solution on vendor platforms and can not be stopped merely by strong process definition at customer site. [8] Platform security is thus one of important threat needs to be address in enterprise edge networking solution which is not observed in offering of any vendor today. Also there are many known ways to make platform secured by making them tamper-proof. But all measures of tamper-proofing will be liquidated if platform is replication-prone. It is desirable that all platforms sitting one edge of multi-site network or wireless mesh networking should subscribe to common trust domain by mutual attestation & certification. In addition to insider threat noteworthy point is that that every node in a wireless mesh network can not be provided physical security and if provided there will be no economic viability. [9] Prior art

[10] 1. Replication-proofing along with tamper-proofing can be done using a trusted platform module (TPM) enabled environment. Attempts of ensuring platform security using hardware secure model (HSM) has been made. But it does not fully achieve the requirement of trusted computing. Though TPM and HSM both offer cryptographic services and cryptographic key storage, special purpose group TCPA (trusted computing platform alliance) describes the trusted computing environment specifications. A TPM is focused on building trust in a computing system, whereas a HSM limits itself to providing cryptographic security services and key storage. A TPM is designed to work alongside a Core Root of Trust (CRTM) on a host system, in order to enable the firmware and software to report the computing systems software state and configuration. A HSM typically only provides cryptographic services and does not provide these mechanisms. In summary, a HSM provides secure execution of cryptographic functions and protection of some secrets and processes, whereas a TPM also provides mechanisms to attest to the trustworthiness (software state and configuration) of a host computing system. A TPM may be implemented in accordance with specifications such as trusted computing group (TCG) TPM specification which includes parts such as design principles, structure of TPM and TPM commands. The TPM specifications are published by TCG and are available from internet at www.trustedcomputing.org/home. Networking platforms need a trusted computing environment to defeat various attacks apart from secure key storage. 2. PCT application no. PCT/1B2007/052219 described method for ensuring platform security addressing problems of vulnerability to tampering & vul- nerability to replication in context of typically one time programmable equipments like voting/betting machines. Also the method described in application requires a separate attestation unit which may not fit in certain application context. Further platforms in certain applications need to be image upgradeable and additionally requires temporary non-trusted mode of operation under control of low level trusted software such that a instrumented image can be loaded for debugging customer issues under live network deployment.

Summary of invention :-

[11] The following description describes methods and apparatus for secured networking platform. Platform with hardware rooted trust is essential to guarantee platform security. Invention in its embodiment describes method of enabling root-of-trust in platforms using provisioning server, a hardware platform with security model provided by TPM like facility. Using its root of trust platform is authenticated on its integrity parameters and identity-uniqueness by central server.

[12] Provisioning server also functions like a image server hosting binary images officially released by platform vendor from where, the customers can remotely upgrade the image on their platform. Platforms are equipped with small integrated OTP (one time programmable) containing trusted code which accepts provisioning transaction by provisioning server first time before the shipment and subsequently whenever they are upgraded following officially releases/patches for bugs and features. Platform OTP resident trusted code receives per-platform unique cryptographic credentials for software modules, hardware and platform uniqueness not known to any insider at any point of time. Trust chain extends in a hierarchal manner from lower level module to higher level module i.e, firmware -> boot-loader -> operating system -> control/data path software modules. Using this credentials platforms ensure replication-proofing among other peers sitting on edge of branches and headquarter of a multi-site network and thus enabling a common trust boundary across geographical boundaries. Replication-proofing comprises of mutual hardware attestation, software certification and platform uniqueness assertion. For purpose of replication-proofing one unit can be configured as master and rest as slaves. [13] Brief description of the drawings

[14] The invention described herein is illustrated by way of example and not by way of limitation in the accompanying figures. For simplicity and clarity of illustration, elements illustrated in the figures are not necessarily drawn to scale. For example, the dimensions of some elements may be exaggerated relative to other elements for clarity. [15] Block Diagram 1: Block diagram describing trusted booting hierarchy, reset vector pointing to OTP trusted code and trust chain extends in hierarchal manner from boot- loader to operating system and from there control/ data-path applications

[16] Block Diagram 2: Block diagram of Provisioning server enabling trust in OTP enabled edge networking platform.

[17] Block Diagram 3: Block diagram of Attestation unit (provisioning server / networking platform in master mode) doing relevant attestation transactions as described under embodiment 1, with networking platform and reports attestation & certification unsuccessful and detection of replicated/tampered networking platform

[18] Block Diagram 4: Block diagram of networking platform in slave mode catching bogus attestation unit (role of attestation unit is performed by provisioning server/ networking platform in master mode)

[19] Block diagram 5: Showing Security Accreditation Record (SAR), shown in clear text for illustration, [platforms will store per-platform unique SAR enciphered by provisioning box TPM secured hardware rooted private key, inside persistent memory of networking platform under protection of trusted code contained in OTP environment OR inside secured model provided by TPM in case the platform is TPM enabled ]

[20] Block diagram 6: Provisioning server embeds security credentials in networking platform enciphered with its hardware rooted private key and Provisioning sever embeds public key associated with hardware rooted private key used to encipher SAR

[21] Block Diagram 7: Shows how the TPM fits into platform architecture and where the various roots of trust reside. These roots of trust provide the means of knowing whether a platform is trusted.

[22] Block diagram 8: Shows the Trusted Platform Module a hardware component that provides four major classes of functions.

[23] Block Diagram 9: Block diagram of Key storage hierarchy

[24] Block Diagram 10: Primary and Backup Provisioning server sync private key as extension of Deffie-Hellman method of key exchange for seamless attestation and certification in case primary provisioning server hardware failure.

[25] Block Diagram 11: Networking platforms on edges of multi-site network in master mode (sitting at edge of head-quarter , for illustration) performs mutual attestation and certification with all other networking platform in slave mode sitting at edge of branch office sites (for illustration) in a multi-site network subscribing to a common trust boundary. Mutual attestation & certification is equally relevant in wireless mesh network to enforce a common trust domain.

[26] Detailed specification of the invention

[27] The following description describes methods and apparatus for provisioning, attestation & certification of networking platform. In the following description, numerous specific details such as logic implementations, types and interrelationships of system components, are set forth in order to provide a more thorough understanding of the present invention. It will be appreciated, however, by one skilled in the art that the invention may be practiced without such specific details. In other instances, control structures, gate level circuits and full software instruction sequences have not been shown in detail in order not to obscure the invention. Those of ordinary skill in the art, with the included descriptions, will be able to implement appropriate functionality without undue experimentation.

[28] References in the specification to 'embodiment', indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure or characteristic in connection with other embodiments whether or not explicitly described.

[29] In the following description and claims, the terms 'crypto', 'crypto protected' should be understood to be asymmetric cryptography unless mentioned otherwise. However asymmetric cryptography not necessarily referring to a particular kind of algorithm either RSA or ECC.

[30] Following is the description of invention with separate details of 'Embodiment 1',

'Embodiment 2' and 'Trusted computing platforms'.

[31] Embodiment 1 :

[32] This embodiment doesn't require every platform to have Trusted platform module like facility instead it contains trusted code in OTP which acts like root-of-trust once provisioned and hence doesn't require hardware upgrade.

[33] Provisioning of networking platform: An abstract scheme of provisioning (002) is shown in diagram 2. Provisioning server (011), shown in diagram 7, sends its customized certificate to networking platform (012) shown in diagram 7, deciphers it using known public key and extracts the public key for the purpose of provisioning- link protection considering insider threat. Using this public key networking platform sends its platform/OTP chip serial number. Serial number is inside chip and can be read only through software and software is under control of trusted OTP environment (001 as shown in diagram 1). Provisioning server (011), shown in diagram 7, verifies the serial number and confirms whether it has not been Provisioned before, if yes then raise a red alert with previous provisioning with timing details and login-id of insider. Provisioning server(011) generates random nonce and offset, calculate the hash digest of networking platform software (a copy of binary image is available with provisioning server), and challenges the networking-platform(012) to authenticate itself with its hash using random nonce at random offset as data of challenge. Networking-platform reports an encrypted record using extracted public key from provisioning server customized certificate. Record contains Hash and key (preferably symmetric for computational efficiency). Provisioning server (Oi l) decrypts the reported record using the private key (associated with public key embedded in its customized certificate). Provisioning server generates encrypted record using symmetric key in previous step. Record contains enciphered SAR (010), shown in diagram 6, using its HW rooted private key, and SAR's (010) clear text HASH. Networking platform decrypts the record with its symmetric key generated earlier and stores the Enciphered SAR (010) and clear text HASH in its persistent memory. Finally Networking platform has its enciphered SAR (010), HASH of clear text SAR(OlO) and its own Serial number as part of per-platform security credentials.

[34] Attestation & certification of platform by attestation unit: Role of attestation unit is performed by provisioning server / another platform in master mode. Attestation unit (003) shown in diagram 3, sends attestation challenge. Networking-platform (004), shown in diagram 3, sends its clear text platform Serial no. and SAR. Attestation unit deciphers SAR(OlO), shown in diagram 6, using public key , extracts & compares embedded serial no with that sent in clear text, by Networking platform in response to attestation challenge. Attestation unit (003), shown in diagram 3, verifies integrity of message using hashing algorithm embedded in SAR (010) to compute hash again to confirm that SAR (010) is intact. Attestation unit (003) extracts random nonce and offset and sends along a certification challenge. Networking platform computes software digest and reports to attestation unit. Attestation unit compares reported digest with that embedded in deciphered SAR (010) .Networking platform challenges attestation unit to report Hash-Digest embedded in SAR (010) and compared reported HASH with that stored in its persistent memory during provisioning. In case attestation unit (003), shown in diagram 3, finds serial number in deciphered SAR (010) not matching with that supplied by Networking platform(004), shown in diagram 3, it report as replicated Networking platform.

[35] Validation of attestation unit: Role of attestation unit is performed by provisioning sever or another networking platform in master mode. Networking platform(OOβ), shown in diagram 4, asks attestation unit (005), shown in diagram 4, to report the calculated HASH of clear text SAR and compares this with that in its persistent storage stored during provisioning process. Since only vendor provisioned Attestation unit can decipher SAR (010) correctly, attestation unit can be validated safely. Optionally for further security a SAR (010) can be provisioned on attestation unit and associated public key on Networking platforms. Networking platform (006), shown in diagram 4, reports in case attestation unit (006), shown in diagram 4, is found bogus & replicated. [36] Provisioning server private key redundancy: For best security purpose since hardware rooted key is not known to any body and it may get lost forever due to hardware failure. Hence redundancy of hardware rooted key while maintaining best possible level of security is desired. While one simple method can be to tunnel its private key of primary (018), as shown in diagram 10, within public key of backup server (019), as shown in diagram 10, which will store the supplied private key in its secured storage for use in provisioning if primary server fails. But this method while optimally safe but not bullet-proof secured. Proposed method is most secured as private key never required to come out of secured hardware rooted storage in any form neither requires any support from TPM vendors.

[37] Expect last step other steps are already known prior-art called Deffie-Hellman key exchange and only last step numbered 6 is proposed as novel.

[38] Step 1, Select Global Public Element between two servers A & B q (prime number ) and a ( a < q and a s primitive root of q) .

[39] Step2 , Server A key generates Private key such as Xa ( Xa < q) and Public key Ya = a^Λ Xa mod q.

[40] Step 3, Server B key generates such as Private key Xb ( Xb < q) & Public key Yb = a^Λ Xb mod q

[41] Step 4, Secret key generation by server A K = (Yb)^Λ Xa mod q

[42] Step 5, Secret Key generation by server B K= (Ya) ^Λ Xb mod q

[43] Step 6, Using known prior -art in previous steps now both servers have got common secret key K. Both server select value of prime number as per a fixed protocol , for example immediate next to K let us say Kl. Select primitive root of Kl let us say al ( known to both servers) . Common Private key of server A and B is now , K

[44] Common Public key of server A & B is now , C = al ^Λ K mod Kl

[45] While this method of private key syncing is bullet-proof secured comparable to security provided by TPM. However limitation of this method is that only one redundancy for private key can be achieved but 1 : 1 redundancy is reasonably sufficient.

[46] Insider threat protection during provisioning: An insider can hack SAR (010), associated serial number and HASH of clear text SAR (010) to replicate a platform by intercepting the communication or can cause middle-man-attack. To protect the above threat, Provisioning server creates its certificate and associated public key is stored in persistent memory of networking platform. This key is used to decipher Provisional certificate and extract public key. During authentication phase Networking platform sends an encrypted record of its hash digest, serial number and newly generated symmetric key. Since this is encrypted by public key it can not be decrypted by public key with intruder. Following this provisioning server sends SAR(OlO), HMAC all encrypted with symmetric key send by networking platform. [47] Enabling non-trusted mode of operation to facilitate loading of instrumented image:

It is common by platform vendor support & maintenance team to give instrumented image to customer towards debugging some technical problem in live network. If such situations appear, then provisioning server can remotely enable the networking platform. However trusted code sitting inside OTP will allow it for certain time-period or only extend this liberty to certain modules and this operation would be logged & accounted under trusted environment extended by OTP. Optionally it can be enabled by jumper settings on board. Noteworthy is that this non-trusted mode of operation will be logged, explicitly indicated and auto- switched to trusted mode after certain period of operation.

[48] Network wide subscription to common trust domain: All platform in a wireless mesh network or sitting on edge of multi-site network, subscribe to a common trust domain (020) as shown in diagram 11. One platform configured in master mode initiates the attestation & certification for all other similar platforms configured in slave mode. All slave platforms also attest & certify master platform on distributed root-of-trust security model.

[49] Embodiment 2:

[50] Every networking platform under this embodiment has Trusted platform module or software emulated TPM facility (in that case, core root of trust is established by provisioning) and hence its hw rooted private key is stored by TPM secured model.

[51] Provisioning sever (Oi l), shown in diagram 7, is an hardware platform with TPM secured model. It has database of every platform public key associated with per- platform TPM secured hardware rooted private key indexed with platform serial number. An abstract scheme of provisioning(002) is shown in diagram 2 .

[52] Provisioning of platform (012), shown in diagram 7, starts with provisioning server sending its customized Self-signed certificate. Networking platform using pre-known public key (stored in its persistent memory) deciphers certificate and extract a public key to be used for local link (RS232 for illustration) protection. Private key associated with this extracted public key is secured by TPM functionalities. Using this extracted public key networking platform sends an encrypted record of its serial number to provisioning server. Provisioning sever first decrypt the record and using serial number as index it extracts the public key associated with platform's TPM secured hardware rooted private key. Provisioning server contains a copy of binary image of network platform and prepares platform specific SAR as described in embodiment 1. Further all security credentials like enciphered SAR (010) or HASH (of clear text SAR) sent by provisioning server to networking platform are first encrypted using platform specific public key and then second encryption by private key associated with public key which is extracted after deciphering provisioning server's certificate. Platform stores its security credentials enciphered SAR, HASH (of clear text SAR) in its TPM secured model.

[53] Attestation & certification of platform: Role of attestation unit can be performed either by provisioning server at vendor premises or another networking platform in master mode. Attestation unit (003), shown diagram 3, sends attestation challenge and networking platform (004), shown in diagram 3, responses with its serial number. Attestation unit indexes this serial number into its database and extracts public key associated with per-platform TPM secured hardware rooted private key indexed by serial number. Attestation unit generates random nonce and encrypts using public key and sends encrypted record to networking platform. Networking platform using its hardware rooted private key decrypts the nonce and reports it back to attestation unit. Attestation unit sends random nonce and random offset as part of hash challenge indexed with serial number reported by networking platform. Networking platform using nonce & offset calculates its hash and report to attestation unit. Attestation unit compares reported hash with stored value indexed with serial number of networking platform for certification process. If Attestation unit (003), shown in diagram 3, finds it does not matches, it reports replicated networking platform(004), shown in diagram 3.

[54] Validation of attestation unit: Role of attestation unit is performed by provisioning sever or another networking platform in master mode. Networking platform(OOβ), shown in diagram 4, asks attestation unit (005), shown in diagram 4, to report the calculated HASH of clear text SAR and compares this with that in its persistent storage, stored during provisioning process. Since only vendor provisioned Attestation unit can decipher SAR (010) correctly, attestation unit can be validated safely. Optionally for further security a SAR (010) can be provisioned on attestation unit and associated public key on Networking platforms. Networking platform (006), shown in diagram 4, reports in case attestation unit (006), shown in diagram 4, is found bogus & replicated.

[55] Enabling instrumented image loading on customer site for debugging purpose: it is common by platform vendor support & maintenance team to give instrumented image to customer towards debugging some technical problem. If such situations appear, then provisioning server can remotely enable the networking platform. However trusted code sitting inside OTP will allow it for certain time-period or only extend this liberty to certain modules and this operation would be logged & accounted under trusted environment extended by OTP. Optionally it can be enabled by jumper settings on board but this non-trusted mode of operation will be logged, indicated and auto-switched to trusted mode after certain period of operation.

[56] Network wide subscription to common trust domain (020) as shown in diagram 11:

All platform in a wireless mesh network or sitting on edge of multi-site network, subscribe to a common trust domain(020) as shown in diagram 11. One platform configured in master mode initiates the attestation & certification for all other similar platforms configured in slave mode. All slave platforms also attest & certify master platform on distributed root-of-trust security model.

[57] Note: under embodiment 2, premium model of device can use TPM and processor in a FGPA. This will ensure that TPM and processor communication is on internal bus to guarantee highest security.

[58] Trusted Computing Platform:

[59] A Trusted (Computing) Platform (TP) is a platform that is trusted by local users and remote entities. To enable a user to trust such a platform, a relationship of trust must be established between the user and the computing platform so that the user believes that an expected boot process, a selected operating system, and a set of selected security functions in the computing platform have been properly installed and operate correctly. The user makes his or her own judgment on whether or not he or she trusts the relationship.

[60] Under the TCG's definition of trust, Trusted Platforms are platforms that can be expected to always behave in a certain manner for an intended purpose. Furthermore, the users do not have to make this decision blindly but rather can request for the platform to prove its trustworthiness by asking for certain metrics and certificates. A Trusted Platform should provide at least these basic features:

[61] Protected Capabilities: the ability to perform computation and securely store data in a trustworthy manner.

[62] Integrity Measurement: the ability to trustworthily measure metrics de-scribing the platform's configuration.

[63] Attestation: the ability to vouch for information.

[64] In essence, these features mean that a Trusted Platform-

[65] should be protected against tampering

[66] be able to attest to the authenticity and integrity of platform code and data

[67] perform guarded execution of code

[68] maintain the confidentiality of sensitive information.

[69] To establish trust, a Trusted Platform can reliably measure any metric about itself and attest to it. Some useful metrics include the software loaded on the platform and any device firmware. The user will then need to verify these metrics against trusted values obtained separately to decide if this platform is trustworthy.

[70] This platform is essential as only software method is not enough to ensure the security of the data to be transferred i.e. loss of confidentiality and theft of assets. Security is all about trust relationship and hence this trust is rooted in hardware platform is not fully secured. [71] The so called Roots of Trust (RT) are components within a Trust Path (TP) that must be trusted unless misbehaviour might not be detected. They provide at least functionality for measurement, storing, and reporting of characteristics that affect the trustworthiness of the platform. Commonly there is one root of trust for each capability:

[72] a Root of Trust for Measurement (RTM)

[73] a Root of Trust for Storage (RTS), and

[74] a Root of Trust for Reporting (RTR).

[75] In the trusted platform specified by the Trusted Computing Group (TCG), the

Trusted Platform Module (TPM) acts as the RTS as well as the RTR(014) whereas the Core Root of Trust for Measurement (CRTM) is most often part of the BIOS.

[76] Root of Trust is created by TPM(013) as shown in diagram 8, on a platform Conceptually, the TPM will create three Roots of Trust on its parent platform that are used to effect trust and security mechanisms:

[77] Root of Trust for Measurement (RTM): reliably measures any user-defined metric of the platform configuration. The RTM(016) as shown in diagram 8, starts out as trusted code in the Platform's Boot ROM but extends its trust domain during system boot to the entire platform through the process of 'inductive trust'. In this process, the RTM measures the next piece of code to be loaded, checks that the measurement is correct and then transfer's control. This process of extending the trust domain continues until the trusted operating system is booted.

[78] Root of Trust for Reporting (RTR): allowed to access protected locations for storage, including the Platform Configuration Registers (PCRs) and non- Volatile memory(009 as shown in Diagram 5), and also attests to the authenticity of these stored values using signing keys. PCRs are storage registers that not only store values but also the order in which the values were put in.

[79] Root of Trust of Storage (RTS): protects keys and sensitive data entrusted to the

TPM. The RTS (015), as shown in diagram 8, basically refers to all the key management functionality, including key generation, key management, encryption and guarded decryption.

[80] The Trusted Platform Module is a hardware component that provides four major classes of functions as shown in Block diagram 4:

[81] Cryptographic functions : (P)RNG, SHA- 1 , HMAC, RSA.

[82] Secure storage and reporting of hash values representing a specific platform configuration.

[83] Protected key and data storage.

[84] Initialization and management functions.

[85] In addition, the following auxiliary functions exist:

[86] Monotonic counters and timing-ticks [87] Non- volatile storage

[88] Auditing

[89] Delegation

[90] Cryptographic Functions:

[91] It is to be noted that the TPM is not a cryptographic accelerator. There are no specified minimum throughput requirements for any of the cryptographic functions.

[92] Random Number Generator: The Random Number Generator (RNG) is the source of randomness in the TPM. It is used for the generation of nonces, keys and the randomness in signatures. The TPM specification allows for both true hardware-based and for algorithmic pseudo random- number generators.

[93] SHA-I Engine: A SHA-I [FIPS 180] message digest engine is primarily used for computing message or data signatures and for creating key blobs. The hash interfaces are also exposed outside the TPM to support measurement during the boot phases.

[94] HMACEngine: The HMAC [RFC2104] calculation provides two pieces of information to the TPM: proof of knowledge of the authorization data (shared secret key K) and integrity of the message M. The used algorithm implementation uses SHA-I as the hash function and a padding ipad (opad) consisting of 64 repetitions of byte 0x36 (0x5C). In the following formula denotes the bitwise xor-operation and k concatenation:

[95] HMAC(K₅M) = SHA- 1 (K opad k SHA- 1 (K ipad k M))

[96] RSA Engine: The RSA asymmetric algorithm is used for digital signatures and for encryption. The PKCS #1 standard [PKCSl] provides the implementation details for digital signature, encryption, and data formats. The RSA key generation engine is used to create signing keys and storage keys. A TPM must support up to 2048-bit RSA keys, and certain keys must have at least a 2048-bit modulus. There is no requirement concerning how the RSA algorithm is to be implemented. TPM manufacturers may use Chinese Remainder Theorem (CRT) implementations or any other method.

[97] Platform Integrity:

[98] Platform Configuration Register (PCR): A Platform Configuration Register (PCR) is a 160-bit storage location for discrete integrity measurements in form of SHA-I digests. There are a minimum of 16 PCR registers which are all inside the shielded location of the TPM.

[99] Integrity Measurement: Integrity measurement is the process of obtaining metrics that reflect the integrity of a platform, storing them, and putting digests of those metrics in the PCRs. Examples for such metrics are the opcode of the operating system or the BIOS configuration settings. The philosophy of integrity measurement, storage, and reporting is that a platform may be permitted to enter any state, including undesirable or insecure states, but that it cannot lie about states that it was or was not in. Starting with the CRTM, there is a bootstrapping process by which a series of trusted subsystem components measure the next component in the chain and record the value in a PCR register (e.g., CRTM ! BIOS ! MBR ! OS ! Application). By these means, software is measured and recorded before it is executed. The recordings cannot be undone until the platform is rebooted.

[100] Integrity Reporting: Integrity reporting is used to determine a platform's current configuration state. The reports are digitally signed, using therefore created Attestation Identity Keys (AIK), to authenticate the PCR values as created by a trusted TPM. To ensure anonymity, different AIKs should be used with different parties. Attestation that a specific AIK really belongs to a trusted platform without disclosure of the actual TPM identity can either be done by using a trusted third party (privacy CA) or by means of Direct Anonymous Attestation (DAA) [HPDAA]. The latter has the advantage that it avoids a possible linkage of the several AIK by the privacy CA.

[101] Protected Key and Data Storage:

[102] Key Storage: The Root of Trust for Storage (RTS) protects keys and data entrusted to the TPM. Due to size imitations, only a small amount of volatile memory(008), where keys are held while performing signing and decryption operations, is provided. Inactive keys are encrypted using an adequate storage key SK), often referred to as the keys parent key (see figure). The so called storage Root Key (SRK) (019) as shown in diagram 9 acts as the root of this key hierarchy and cannot be removed from the PM. However, a new SRK may be created as part of the take-ownership process. This has the side-effect that data objects controlled by the previous SRK are no longer accessible.

[103] Further, the TPM can also be used to create new signing or storage keys that can either be bound to it or marked as migratable. In addition to the specific key parameters (key length, usage, authorization data, etc.) the keys parent key has also to be specified. A new created key is not automatically loaded into the TPM but encrypted using the given parent key and returned to the user. Hence, it has to be explicitly loaded before usage.

[104] Data Protection: The TPM specification defines four classes of data protection:

Binding, Sealing (Sealed-Binding), Signing, and Sealed-Signing. Due to the limited data size that can be directly protected (_210 bytes with a 2048-bit RSA key) not the confidential data itself but a symmetric key which is used to (de-)encrypt the data is typically protected.

[105] Binding is the operation of encrypting data using a public key. The data is only recoverable by decrypting it with the corresponding private key. If the private key is managed by the TPM as a non-migratable key, only the TPM that created the key may use it. Hence, the data might be seen as bound to a particular TPM. However, as it is possible to create migratable private keys that are transferable between multiple TPM devices, binding has no special significance beyond encryption.

[106] Sealing takes binding one step further inasmuch as the data are not only encrypted but also bound to a specific platform configuration. Sealing associates the encrypted data with a set of PCR-register values and a non-migratable asymmetric key. The TPM only decrypts the data when the platform configuration matches the specified PCR- register values. Sealing is a powerful feature of the TPM as it provides assurance that the protected data is only recoverable when the platform is in a specific configuration.

[107] Signing of a data digest is only possible with signing only keys. These keys cannot be used for encryption and therefore avoid that a malicious user can encrypt an accordingly prepared data object and misuse it as a valid signature.

[108] Sealed Signing operations can also be linked to PCR registers to ensure that the platform that signed the data meets a specific configuration. When a verifier demands that a signature must include a particular set of PCR registers, the specified registers are added to the data and included into the computation of the signature.

Claims

Claims[1] I Claim:

1. A networking solution platform,

With hardware rooted trust as root of trust using TPM like functionalities such that it is operable only with authorized image and all platform subscribing to a common trust domain in a multi-site network or wireless mesh network ; Vendor premises located Provisioning server for provisioning, attestation, certification accounting, auditing and re-provisioning during image upgrade of networking platform in trusted and even insider-threat protected manner;

Customized security accreditation record (SAR) enciphered with provisioning server TPM secured hardware rooted private key and being used as unique Security credentials per platform.

2. A method of attestation, wherein originality of look-alike functionally equivalent networking platform is determined by extracting serial no. from deciphered SAR and comparing with serial number reported by platform; and attestation unit is also authenticated by networking platform by challenging it to produce hash of deciphered SAR and comparing the reported with one in its persistent memory, received at time of provisioning.

3. A method of electronic certification as in claim 2, wherein networking platform software integrity is electronically certified by challenging it to produce hash digest of its binary image using random nonce at random offset as found in SAR after deciphering by attesting unit and comparing reported hash with that embedded in deciphered SAR.

4. Networking platform with trusted code contained in its integrated OTP acting as root-of-trust once provisioned, such that even equipment vendor can not replicate the device, providing the complete trusted environment.

5. A method of subscription to a common trust domain spread across a multi-site network or wireless mesh network, wherein one platform configured in master mode performs attestation & certification of all other similar platform configured in slave mode.

6. A method of establishing multi-site network wide common trust domain based on distributed root-of-trust model wherein, platform operating in master mode also gets mutually attested & certified by all slave platforms to defeat tampering & replication of master unit itself.

7. A method of cloning trusted platforms used by provisioning server of claim 1, wherein syncing of private key with redundant provisioning servers providing 1 : 1 redundancy by having identical private key at both provisioning servers and which is generated using following three numbers, a.generated common secret key through Deffie-Hellman method b.newly selected common prime number and c. Primitive root to common prime number, it generates a common private/ public key on both provisioning servers without need of tunnelling.

8. A customized security accreditation record SAR as in claim 1, wherein apart from ensuring platform- security by unique credentials at hardware, software and platform uniqueness level not known to any insider at any point of time and thus making them replication-proof and tamper-proof, and extending 360 degree accountability, verifiability and auditability.

9. A method of enabling non-trusted mode of operation either remotely through vendor premises located provisioning server or locally through jumper setting on board, wherein platform is enabled to load a instrumented image or particular module image for debugging in live network, under control of trusted environment provided by OTP/TPM on platform which does accounting, logging and explicit indication of non-trusted mode operation and auto-switch to trusted mode after certain period of operation.