4. DESCRIPTION
The following specification describes the nature of this invention:- Technical field of invention
This invention belongs to the field of attestation and certification of embedded computing platforms [illustrated in context of poll-place E-Voting] Background & prior art
Platform security is central concern for remote e-voting application. 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. Apart from tangible assurance about originality of platform, there should be some external mechanism that can certify that platform computing software has not been tampered or corrupted due to intentional or unintentional reasons to the satisfaction of common electorates, democratic interest groups and poll-observers. All other native integrity check measure will report whatever they are told to, on a replicated platform. Apart from this there should be a maximum security from insider of e- voting platform vendor so that neither he can attempt to make a replicated platform or connive with outsiders by leaking documents, specifications. Hence tampering only solves half of the security problems and an external attestation unit is required to confirm the integrity of platform, to win the public confidence.
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 ai-e available from internet at www.trustedcomputing.org /home. E-voting platforms need a trusted computing environment to defeat various attacks apart from secure key storage.
Platform insecurity in context of poll-place e-voting, can be broadly categorized in three classes.
Vulnerability to tampering, where the desired functionality of the platform is changed by effecting alteration in hardware or software to suit the motive of intruder.
Vulnerability to replication, where replace the original or genuine platform with a functionally equivalent look-alike platform
Voting device design has to be immune from insider threat. Insider threat implies here leakage of design document, specifications from vendor premises either intentionally or unintentionally. Temptation, Influence, threat and connivance all comes under wider definition of insider threat. Process definition, human supervision and due diligence by Election commission combined together is not a full-proof solution to defeat threat of replication.
Summary of invention :-
The following description describes methods and apparatus for secured e-voting platform. While Platform with hardware rooted trust is essential to guarantee platform security, invention in one of its embodiment also describes method of enabling attestation & certification on OTP(one time programmable) platforms without doing hardware upgrade (suited for well accepted embedded computing platforms) using provisioning server, a hardware platform with security model provided by TPM like facility. Hardware rooted trust is being explored for many purposes apart from ensuring that platform is maximally secured against an insider threat as well. Using its root of trust platform is authenticated on its integrity parameters and identity-uniqueness by central server. Master unit communicates to its ballot unit under crypto protected session to detect any corruption of traffic intentionally or unintentionally. To win public confidence & liquidate any possibilities of litigations or disputes, there should be a tangibly trusted way to configure different parameters during deployment. Platform originality and its integrity should be tangibly assured to common electorates, contestants, democratic interest groups and poll-observers. Using a external attestation unit platform originality can be confirmed. Attestation unit has also a electronic certification feature to establish no tampering has happened. Apart from this attestation unit can be used to account and audit the platform in pre-poll & post-poll phase. Attestation unit being trusted, dedicated and mutually authenticable unit can be used to configure the e-voting platform during pre-poll preparedness. Attestation unit can be used to negate false voting by statically uploading per-polling booth electorate authentication data under hash protection directly controlling release of ballot. Novelty is that one hand it avoids voting secrecy intrusion arguments on another hand it avoids any use of network communication, biggest threat in e-voting model. While fingerprint data is not ready it can be used for post-poll authenticated repudiation of false voting being effective from day one.
Brief description of the drawings
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.
Block Diagram 1: Block diagram of voting machine along with hardware rooted trust module ( TPM, for illustration)
Block Diagram 2: Block diagram of Attestation unit doing attestation & certification transactions with e-voting platform: Attestation unit does relevant transactions as described under embodiment 1, with e-voting platform and reports attestation & certification successful.
Block Diagram 3: Block diagram of Attestation unit doing relevant transactions as described under embodiment 1, with e-voting platform and reports attestation & certification unsuccessful and detection of replicated e-voting platform
Block Diagram 4: Block diagram of Attestation unit doing attestation & certification transactions with e-voting platform. Attestation unit falsely reports attestation & certification successful. But e-voting platform detects this and reports bogus attestation unit.
Block diagram 5: Showing Security Accreditation Record (SAR), shown in clear text for illustration. [E-voting platforms will store per-platform unique SAR enciphered by provisioning box TPM secured hardware rooted private key, inside persistent memory of voting platform under OTP environment OR inside secured model provided by TPM in case the platform is TPM enabled]
Block diagram 6: Provisioning server first authenticates itself through its self-signed certificate (decipherable by a pre-known public key). Provisioning local link (serial RS232 for illustration) is encrypted by public key extracted from deciphered certificate and provisioning server decrypts it using associate private key PI stored under secured model of TPM(for illustration) and embeds security credentials in e- voting platform enciphered with its hardware rooted private key
Block diagram 7: Provisioning sever embeds public key associated with hardware rooted private key P2 stored under secured model of TPM (for illustration) used exclusively to encipher SAR.
Block Diagram 8: 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.
Block diagram 9: Shows the Trusted Platform Module a hardware component that provides four major classes of functions.
Block Diagram 10: Block diagram of Key storage hierarchy
Detailed specification of the invention
The following description describes methods and apparatus for attestation & certification of e-voting 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.
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.
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.
One of the embodiments of the invention is described below.
Attestation and certification using handheld portable attestation unit: This is for the purpose of Tangible assurance to electorates, democratic interest groups and contestants about integrity and originality of e-voting platform in both cases i.e. poll- place e-voting OR remote e-voting. Attestation unit and e-voting platform should be provisioned and manufactured by same vendor as of e-voting platform for best security. Provisioning box will be a platform with hardware rooted trust. Provisioning server would be at vendor's premises and is trusted computing environment. It authenticates both attestation unit and e-voting platform before provisioning. Provisioning box will have exact binary image of attestation unit and e-voting platform both. Optionally for better security Provisioning server would be supplied with hash-protected data of the serial number of bulk amount of micro¬controller/ cpu chips before every lot of voting platform to be manufactured. Provisioning box will provide tamper-proof verifiable and auditable environment for every platform provisioned due to trusted platform module. Provisioning server use two private key under secured model of TPM. First private key PI is associated with public key embedded in its self signed certificate for authentication purpose, this public key can be extracted after deciphering certificate using a pre-known public key. Second private key P2 is exclusively for purpose of signing SAR (010), as shown in diagram 5, and its associated public key is embedded in attestation unit (014), as shown in diagram 7.
Provisioning of e-voting platform: Provisioning server (Oil), shown in diagram 6, sends its customized certificate Voting-platform (012) shown in diagram 6, deciphers it using pre-known public key stored in its persistent memory and extracts the public key for the purpose of provisioning-link protection considering insider threat. Private key PI associated with extracted public key from provisioning server's certificate is stored under secured model of TPM. Using this public key voting platform sends its platform/OTP chip serial number. Serial number is inside chip and can be read only through software and software should run under OTP environment for best security. Provisioning server (Oil), shown in diagram 6, decipher & 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 (Oil) generates random nonce and offset calculate the hash digest of voting platform binary image (Provisioning server has copy of binary image as data), and challenges the voting- platform (012) to authenticate itself with its hash using same random nonce at random offset as challenge. Voting-platform reports an encrypted record of calculated hash using extracted public key from provisioning server customized certificate. Encrypted Record additionally contains a key (preferably symmetric for computational efficiency) along with HASH. Provisioning server (Oil) decrypts the reported record using the private key PI (associated with public key embedded in its customized certificate). Provisioning server generates encrypted record using symmetric key in previous step. Record contains pre-enciphered SAR (010), shown in diagram 5, (using its Hardware rooted private key P2 exclusively used for signing SAR), and SAR's clear text HASH. Voting platform decrypts the record with its symmetric key generated earlier and stores the Enciphered SAR (010), as shown in diagram 5, and clear text HASH in its persistent memory. Finally e-voting platform has its enciphered SAR (010), HASH of clear text SAR(010) and its own Serial number as part of per-platform security credentials.
Provisioning of attestation unit: Provisioning box (013), shown in diagram 7, and attestation unit (014), shown in diagram 7, both authenticate each other. While Attestation unit authenticates provisioning box through its self-signed certificate. Provisioning box already have a copy of binary image of attestation unit image and it authenticates attestation unit by challenging it to produce its binary image hash digest using a random nonce at random offset generated by provisioning box uniquely for every provisioning. Once authentication phase is over, provisioning box embeds the public key associated with its hardware rooted private key P2 exclusively used for signing SAR(010), as shown in diagram 5.
Attestation & certification of voting platform by attestation unit: Attestation unit (003) shown in diagram 2, sends attestation challenge. Voting-platform (004), shown in diagram 2, sends its clear text platform Serial no. and SAR(010), as shown in
/-N
diagram 5,. Attestation unit deciphers SAR (010), shown in diagram 5, using public key, extracts & compares embedded serial no with that sent in clear text, by voting platform in response to attestation challenge. Attestation unit (003), shown in diagram 2, verifies integrity of message using hashing algorithm embedded in SAR (010) to compute hash again to confirm that SAR (010), as shown in diagram 5, is intact. Attestation unit (003) extracts random nonce and offset and sends along a certification challenge. Voting platform computes digest and reports to attestation unit. Attestation unit compares reported digest with that embedded in deciphered SAR (010) .Voting 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 (005), shown in diagram 3, finds serial number in deciphered SAR (010) not matching with that supplied by voting platform(006), shown in diagram 3, it report as replicated e- voting platform.
Validation of attestation unit: E-voting platform (008), shown in diagram 4, asks attestation unit (007), 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 e-voting platforms. Voting platform (008), shown in diagram 4, reports in case attestation unit (007), shown in diagram 4, is found bogus & replicated.
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 within public key of backup server 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.
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. 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).
Step2 , Server A key generates Private key such as Xa ( Xa < q) and Public key Ya = aA Xa mod q.
Step 3, Server B key generates such as Private key Xb (Xb < q) & Public key Yb = aA Xb mod q
Step 4, Secret key generation by server A K = (Yb)A Xa mod q
Step 5, Secret Key generation by server B K= (Ya)A Xb mod q
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 K1 let us say
al (known to both servers). Common Private key of server A and B is now, K
Common Public key of server A & B is now, C = al A K mod Kl
While this method of private key syncing is bullet-proof secured comparable to security provided by TPM but limitation of this method is that only one redundancy for private key can be achieved.
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 e-voting platform. This key is used to decipher Provisional certificate and extract public key. During authentication phase E-voting 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(OIO), HMAC all encrypted with symmetric key send by e-voting platform.
For voting application network based communication and bogus/false voting is
biggest challenge involving technical & legal issues. Attestation unit can be used in novel way where during pre-poll preparedness per-polling booth authentication data of electorates are statically uploaded on attestation unit .This data is hash-protected and hash value per-polling booth after every upgrade of electoral-roll is publicly known to detect and defeat any insider attack. Attestation unit sends ballot-release signal only after successful authentication. However manual release of ballot by presiding officer is allowed by attestation unit to the extent of the portion of electoral-roll not covered under authentication-data, hence interoperable with fully or partially electoral-roll covered under authentication data. Attestation unit informs voting platform about extent of manual release acceptance at start of poll. Since attestation unit is processing the authentication data, while ballots are being stored in voting platform without any notion of sequencing, any possible argument of voting secrecy intrusion is also liquidated.
For Populous democracies with growing populations creating and maintaining authentication data is a complex challenge. Attestation unit can be used for innovative process pf post-poll authentic repudiation of false voting without requirement of pre-enrolled fingerprint database from day one. During polls presiding officer collects fingerprint database along with electoral roll serial number on attestation unit. Post-poll phase poll-observer invites repudiation of bogus voting where genuine electorates are required to authenticate their repudiation by submitting finger-print. Being trusted dedicated and mutually authenticable by voting platform, Attestation unit provides a trusted repudiation platform beyond any scope of litigation and dispute along with trusted auditing and reporting. This way attestation unit offers after fully predictable authenticated repudiation facility, defeating all arguments of voting secrecy intrusion. To liquidate privacy arguments its functional specifications are sufficient. Being trusted it absolutely guarantee that authentication data will never come out of device. Being trusted it automatically purges authentication data capture either during poll or repudiation, after a fixed time or repudiation whichever happens earlier. Through a proprietary algorithm it stores all authentication data enciphered, hence unusable for any other purpose.
Another embodiment of the invention is described below.
Every e-voting platform (001), as shown in diagram 1, under embodiment has Trusted platform module (002), as shown in diagram 1, and hence its hw rooted private key on its TPM secured model. Upside is that security is more but attestation unit database has to be refreshed before every election as voting platforms are shipped. Downside is that it may not be seamless attestation (any attestation unit attesting any voting platform). Also cost & logistical difficulties are in periodic refreshment of database. Putting TPM hardware on every voting platform increases the cost and it requires hw upgrade.
Provisioning sever (Oil), shown in diagram 6, 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. Provisioning server use two private key under secured model of TPM. First private key PI is associated with public key embedded in its self signed certificate for authentication purpose, this public key can be extracted after deciphering certificate using a pre-known public key. Second private key P2 is exclusively for purpose of signing SAR (010), as shown in diagram 5, and its associated public key is embedded in attestation unit (014), as shown in diagram 7.
Provisioning of e-voting platform (012), shown in diagram 6, starts with provisioning server (011), shown in diagram 6, sending its customized Self-signed certificate. E-voting 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 PI associated with this extracted public key is secured by TPM functionalities within provisioning server TPM secured model. Using this extracted public key e-voting 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 TPM secured hardware rooted private key. Further all security credentials like enciphered SAR (010) or HASH (of clear text SAR) sent by provisioning server to e-voting platform are encrypted using platform specific unique public key . Platform stores its security credentials enciphered SAR, HASH (of clear text SAR) in its TPM secured model after decrypting the record sent by provisioning server using its TPM secured hardware rooted private key.
Provisioning of attestation unit (014), shown in diagram 7, is also in similar model as that of e-voting platform. Difference is that Attestation unit is provisioned with public key P2 associated with provisioning server TPM secured hardware rooted private key used for enciphering SAR.
Attestation & certification of e-voting platform: Attestation unit (003), shown diagram 2, sends attestation challenge and voting platform (004), shown in diagram 2, 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 voting platform. Voting 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 voting platform. Voting 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 voting platform for certification process. If Attestation unit (005), shown in diagram 3, finds it does not matches, it reports replicated e-voting platform(006), shown in diagram 3.
Though Attestation unit is shown as dedicated embedded computing platform but the attestation & certification can also performed by VPN enabled provisioning server at vendor premises. Even if poll-place e-voting platform are not network enabled but through their IO they can interface with any machine which can in turn communicate with provisioning server over a VPN tunnel and communicate on behalf of e-voting platform doing attestation & certification related transactions.
Maintaining hash values of four sections separately in PCR (016), shown in diagram 9, First stage firmware (platform initialization), boot-loader (loading the operating system), Operating system and Voting application.
Comparing the hash value of execution matrix (code, memory occupancy, network buffers, cpu utilization) for anomaly detection or virus attacks [only for remote voting] with respect to known reference values during certain stages of voting i.e. (when ballot has been sent or stored in memory in case of offline mode of operation) and in case of anomaly detection, restart the voting unit or take corrective action.
Ballot-unit also may be TPM protected especially for code-integrity check and sanity of hardware. Ballot unit and master unit will communicate under a authenticated session using hardware rooted trust provided by there respective TPM chips. Additional advantage of doing this is that any data corruption between both unit and even a intentionally effecting voltage variation on interconnect cable, is detected and polling can not take place unless corrective actions are taken.
A device with all the above mentioned programs shall become a premium model, which shall use TPM and processor in a FGPA or one time programmable module. This will ensure that TPM and processor communication is on internal bus to guarantee highest security.
For voting application network based communication and bogus/false voting is biggest challenge involving technical & legal issues. Attestation unit can be used in novel way where during pre-poll preparedness per-polling booth authentication data of electorates are statically uploaded on attestation unit. This data is hash-protected and hash value per-polling booth after every upgrade of electoral-roll is publicly known to detect and defeat any insider attack. Attestation unit sends ballot-release signal only after successful authentication. However manual release of ballot by presiding officer is allowed by attestation unit to the extent of the portion of electoral-roll not covered under authentication-data, hence interoperable with fully or partially electoral-roll covered under authentication data. Attestation unit informs voting platform about extent of manual release acceptance at start of poll. Since attestation unit is processing the authentication data, while ballots are being stored in voting platform without any notion of sequencing, any possible argument of voting secrecy intrusion is also liquidated.
For Populous democracies with growing populations creating and maintaining authentication data is a complex challenge. Attestation unit can be used for innovative process pf post-poll authentic repudiation of false voting without requirement of pre-enrolled fingerprint database from day one. During polls presiding officer collects fingerprint database along with electoral roll serial number on attestation unit. Post-poll phase poll-observer invites repudiation of bogus voting where genuine electorates are required to authenticate their repudiation by submitting finger-print. Being trusted dedicated and mutually authenticable by voting platform, Attestation unit provides a trusted repudiation platform beyond any scope of litigation and dispute and provides trusted auditing and reporting. This way attestation unit even after fully predictable authenticated repudiation facility it defeats all arguments of voting secrecy intrusion. To liquidate privacy arguments its functional specifications are sufficient. Being trusted it absolutely guarantee that authentication data will never come out of device. Being trusted it automatically purges authentication data capture either during poll or repudiation, after a fixed time or repudiation whichever happens earlier. Through a proprietary algorithm it stores all authentication data enciphered, hence unusable for any other purpose.
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.
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:
Protected Capabilities: the ability to perform computation and securely store data
in a trustworthy manner.
Integrity Measurement: the ability to trustworthily measure metrics de-scribing
the platform's configuration.
Attestation: the ability to vouch for information.
In essence, these features mean that a Trusted Platform— should be protected against tampering
be able to attest to the authenticity and integrity of platform code and data
perform guarded execution of code
maintain the confidentiality of sensitive information.
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.
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.
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:
a Root of Trust for Measurement (RTM) a Root of Trust for Storage (RTS), and
a Root of Trust for Reporting (RTR) (015) as shown in diagram 9, 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 whereas the Core Root of Trust for Measurement (CRTM) is most often part of the BIOS.
Root of Trust is created by TPM 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:
Root of Trust for Measurement (RTM): reliably measures any user-defined metric of the platform configuration. The RTM 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.
Root of Trust for Reporting (RTR): allowed to access protected locations for storage, including the Platform Configuration Registers (PCRs) and non-Volatile memory, 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.
Root of Trust of Storage (RTS): protects keys and sensitive data entrusted to the TPM. The RTS basically refers to all the key management functionality, including key generation, key management, encryption and guarded decryption.
The Trusted Platform Module is a hardware component that provides four major classes of functions as shown in Block diagram 4:
Cryptographic functions: (P)RNG, SHA-1, HMAC, RSA.
Secure storage and reporting of hash values representing a specific platform
configuration.
Protected key and data storage. Initialization and management functions.
In addition, the following auxiliary functions exist: Monotonic counters and timing-ticks Non-volatile storage
Auditing Delegation
Cryptographic Functions
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.
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.
SHA-1 Engine: A SHA-1 [FIPS180] 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.
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-1 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:
HMAC(K,M) = SHA-1 (K opad k SHA-1(K ipad k M»
RSA Engine: The RSA asymmetric algorithm is used for digital signatures and for encryption. The PKCS #1 standard [PKCS1] 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.
Platform Integrity
Platform Configuration Register (PCR): A Platform Configuration Register (PCR) is a 160-bit storage location for discrete integrity measurements in form of SHA-1 digests. There are a minimum of 16 PCR registers which are all inside the shielded location of the TPM.
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.
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.
Protected Key and Data Storage
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, 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) acts as the root of this key hierarchy (017), as shown I diagram 10, 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.
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.
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.
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.
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.
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.
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.

5. CLAIMS I Claim:
1. A e-voting device comprising,
Hardware rooted trust as root of trust using TPM like functionalities; External handheld or portable attestation unit for attestation, certification accounting, auditing and configuration of remote e-voting platform in trusted and even insider-threat protected manner;
Provisioning server for provisioning e-voting platform and attestation unit at e-voting device vendor premises;
Customized security accreditation record (S AR) enciphered with provisioning server TPM secured hardware rooted private key and being used as unique Security credentials per e-voting platform.
2. A method of attestation as in claim 2, wherein originality of look-alike functionally equivalent E-Voting platform is determined by extracting serial no. from deciphered SAR and comparing with serial number reported by platform; and authenticator unit is also authenticated by e-voting platform by asking it to produce hash of deciphered SAR and comparing with one in its persistent memory, received at time of provisioning.
3. A method of electronic certification as in claim 2, wherein e-voting platform integrity is electronically certified by challenging it to produce hash digest of its binary image using random nonce at random offset as found in deciphered SAR and comparing reported hash with that embedded in deciphered SAR.
4. A method of accounting, auditing and configuration of e-voting platform as in claim 2, wherein trusted feature is used for doing accounting & auditing in pre-poll & post-poll phase along with important configurations in a trusted, auditable, tamper-proof and verifiable manner and hence facilitating secured asset management for inventory of e-voting platforms.
5. Attestation unit as in claim 1, wherein per-polling booth electorate data under hash protection is statically uploaded and ballot is released in e-voting platform only after successful authentication of electorates, avoiding the any possibility of voting secrecy intrusion arguments.
6. Attestation unit as in claim 1, wherein trusted & mutually authenticable with e-voting platform is used for post-poll authenticated repudiation of false voting using authentication module.
7. Attestation unit as in claim 1, wherein authentication data captured during polling and during post-poll repudiation is stored in proprietary encrypted, automatically purged after a fixed time or repudiation whichever is earlier, authentication data never comes out of unit , all these together can be guaranteed attestation unit being trusted & mutually authenticable by e-voting platform and hence privacy intrusion is avoided.
8. E-voting platform with Trusted platform module kind of hardware rooted trust such that even equipment vendor can not replicate the device, providing the complete trusted environment and overcomes the limitation of HSM
9. A platform in claim 3 communicating under a crypto session with its ballot unit to detect any possible corruption of data on interconnect cable intentionally and unintentionally.
10. A Remote e-voting platform as in claim 1, wherein master unit on behalf of ballot unit, acting as proxy and using its hardware rooted trust provided by its TPM, performs authentication transactions to attestation unit, such that additional 10 is not required on ballot unit.
11. Provisioning server of claim 1, used to provision attestation unit and e-voting platform sync private key with a backup provisioning servers providing 1:1 redundancy in a bullet-proof secured manner and resulting in identical private
key on both provisioning server otherwise TPM secured hardware rooted key can be lost following a hardware failure on main provisioning server.
12. A customized security accreditation record SAR as in claim 1, wherein apart from ensuring platform-security by making them replication proof, it also provides a way of ensuring integrity of embedded computing platform confirming it has not been tampered or corrupted due to any unintentional reasons, helping in tangible assurance about a e-voting platform integrity.