News What Is This? Theory Security Security Model Cryptographic Peculiarities IBM Security Privacy Try It Out! FAQs Presentation Download

RPOW Security Overview The RPOW server is designed to provide security and reliability through an unprecedented degree of visibility and transparency in its operations. For the first time it will be possible for any user of the system, anywhere in the world, to know what code is running on the server and to inspect that code for loopholes or back doors. I have done my best to make this system secure even against my efforts as the owner, operator and designer of the system to compromise its operations. I welcome public scrutiny of the code and of the design. The RPOW system represents a new kind of security model, and is therefore unusually challenging to present and to review. RPOW combines an exceptional degree of physical security with an unprecedented level of transparency and visibility into the workings of the RPOW server. This combination implements the design goal of RPOW as a "Transparent Server", a system whose security properties can be analyzed and evaluated from any system on the internet. In operation, the RPOW system consists of three parts: the server, the host process, and the client library with its associated demo driver. We will consider each part in turn. The RPOW Server First is the RPOW server itself, which runs on an IBM 4758 Secure Cryptographic Coprocessor (SCC). The IBM 4758 is a single-board computer which plugs into a PCI expansion slot of an ordinary Intel compatible PC. Validated to FIPS-140 level 4, the 4758 is resistant to a wide range of physical attacks, including temperature variations, radiation, and electrical bursts. It is surrounded by a tamper-sensitive mesh which automatically and permanently zeroizes sensitive data if an attack is detected. The 4758's physical security is overkill for this application, the system being designed for secure financial transactions where substantial sums of money are at risk. RPOW tokens carry no monetary value and represent only computer cycles. However, the 4758 does have one property which, as far as I have been able to determine, is unique at this time, and which enables the RPOW security model to work. That is the ability of the 4758 to produce what it calls an Outbound Authentication. In other contexts this is known as Remote Attestation. What it means is that the card can securely report a hash or fingerprint of the software configuration which is running there. This capability is the key to RPOW's security. It is what allows users to validate that the published source code is what is running on the 4758, and therefore that there are no "back doors" or secret commands which the operator can use to defeat the security of the system. In order to implement the Outbound Authentication, the 4758 needs several components. One is a device private key, burned into the card at manufacture time and never changed or allowed to leave the card. Another necessary ingredient is a certificate, issued by IBM, which validates that the device public key is in fact a key whose private part resides in an authentic IBM 4758 device. And the third part is the certificate chain issued by the device private key, which attests to the hash(es) of the software loaded onto the card. Because the 4758 was designed in the early 1990s, it uses some cryptographic formats and algorithms which are different from the ones which went on to become standards. Follow this link for more details on the 4758's cryptographic peculiarities. Despite these quirks, the 4758's use of cryptography is fundamentally sound. The device is widely used by banks and other members of the financial services industry. Using this certification chain, the 4758 provides a signed statement which attest to the software configuration of the card. Ultimately, however, it is necessary to depend on the integrity of IBM in order to trust the information provided by the 4758. See the IBM Security page for discussion of the dependency of RPOW on the proper behavior of IBM and its agents. RPOW Untrusted Host The RPOW server runs on an IBM 4758 Secure Cryptographic Coprocessor card, which is a PCI card that can be installed on any ordinary PC. The 4758 does not have a direct connection to the outside world, but rather, software must run on the host computer to communicate with the card. In the case of RPOW, this host software listens for connections from the Internet and passes the data back and forth to the card. It also performs certain housekeeping functions, such as initializing the card for initial key generation, and managing key rollover and import of trusted keys from other cards, as described on the World of RPOW page. A key concept in the RPOW architecture is that the host computer is untrusted. It does not fall within the 4758 security boundary and there is no remote attestation or tamper resistance to allow RPOW clients to have any confidence about the software running on the host. The host software may misbehave in a variety of ways without RPOW users being able to detect it. For the purposes of the security analysis, we assume that the host software is actively hostile and will take every advantage available to it to attack the security goals of the RPOW system. There is, however, one aspect of the RPOW system which is inherently vulnerable to the host's cooperation, and that is availability. Obviously a hostile host (or system owner) could take an RPOW server offline at any time. We can't do anything about that. One concern is that in the future, if a system like RPOW became popular, even though a system owner wasn't able to make the server cheat, he could blackmail users by threatening to shut down the server, which would prevent further RPOW exchanges. The best solution I have for that at this time is to diversify the system along the lines discussed in the World of RPOW page. Once RPOW servers are in operation at a variety of sites all over the world, the leverage of any one operator over the system would be relatively small. And initially, it is certainly my intention to make the RPOW server as reliable and available as possible, in order to help people find uses for this new technology. Assuming that availability is addressed, the host computer may have more subtle attacks in mind. It could try to get the RPOW server to create RPOW tokens without paying for them. It could try to eavesdrop on incoming RPOW exchange requests and divert the incoming or outgoing RPOWs to itself instead of to the proper owner. And it could try to impair users' privacy by correlating RPOW withdrawals and later deposits, in order to track patterns of RPOW transfers and build up a revealing database of who is communicating with whom. These are the kinds of attacks that the RPOW design is directly intended to defend against. RPOW clients set up a secure communication channel to the server by using the RPOW communication key which is exported by the RPOW server within the certificate chain that is produced by the 4758. This certificate chain goes back to the IBM root key and proves that the keys involved come from a genuine IBM 4758 board and from the RPOW server program, as described above. No other entity than the genuine RPOW server program can create such a certificate chain, and this fact is verifiable by the RPOW client. By using the RPOW communications key to encrypt all traffic between the client and RPOW server, users are protected against the host eavesdropping on the message and learning any details about what POWs and/or RPOWs are being exchanged. See the Privacy page for details on how RPOW protects private information from the untrusted host. The impossibility of the host getting the RPOW server to create tokens without paying for them is another of the main security goals of the system. Study of the source code will show that there are no "back doors" which could allow any entity to get the RPOW server to sign tokens worth more than those which are being deposited. It is this feature which ultimately allows users to trust that RPOW tokens have value in the same sense that POW tokens do, that they are as rare and difficult to create as the POW token which they originally came from. Seen-RPOW Database The untrusted host plays one other important role in the RPOW system. It maintains the database of all POW and RPOW tokens which have been exchanged at the RPOW server in the life of the system. Such a database is necessary to ensure that no one can exchange a given POW or RPOW token more than once and get a new RPOW for it. This is part of the "no inflation" principle which requires every RPOW token in circulation to ultimately be traced back to a unique POW token. Unfortunately, the memory capabilities of the IBM 4758 board are somewhat limited, about two megabytes of memory available. This is not enough to hold the seen-RPOW database for the expected lifetime of the system, if it should become heavily used. In order to hold information about all the POWs and RPOWs ever seen, the 4758 must rely on the untrusted host to hold the data. It may seem paradoxical to speak of an untrusted host holding a database whose integrity is absolutely crucial if RPOW is to meet its security goals. If the host were able to alter the database, even to be able to roll back its state to an earlier but then-valid version, it could easily create multiple RPOWs from a POW and violate the RPOW security. It could simply deposit a POW or RPOW, perhaps a high-value one, and receive an RPOW in return. Then it could roll back the database to an earlier state, or perhaps simply refuse to record the entry of the deposited token, and exchange it again. Since the RPOW server is relying on the host to record the information about which tokens it has seen, the host could trivially create as many RPOWs as it wanted from a single POW or RPOW token. Such a capability would be devastating to the security of the RPOW system and make RPOWs be worthless as tokens of value. The solution is to use techniques from the cryptographic community. There is an extensive literature on the concept of validating certain operations on a remote and untrusted host. As it happens, storing entries in a database is one of the simplest and most easily implemented tasks among those which have been studied. The RPOW server stores the information about previously-seen tokens in a tree-structured database built around the data structure known as a B-tree. B-trees are "balanced" trees, meaning that the depth to every leaf node is the same. They are generally wide, with branching factors of hundreds or even thousands. This makes them well suited for storing large amounts of data on a disk, as only a small, essentially constant number of seeks and reads are necessary to find a data item. In the case of RPOW, the B-tree has a branching factor of 100, and the data stored is a SHA-1 hash of the POW or RPOW token data. However, it is not a pure hash, but rather, a secret, constant 64-bit string is prefixed to the POW/RPOW token data before it is hashed. This hash operation is done on the 4758 RPOW server, which then passes the result to the untrusted host for a database query. By using the secret prefix, essentially no information is leaked to the host about the information in the token. (But see the page on Privacy for an important caution about the extent of secrecy here.) The method used to enforce correct behavior on the part of the untrusted host is a cryptographic concept called a Merkle hash tree. In a Merkle hash tree, every node in the tree has associated with it a hash value. (This hash value is another concept, distinct from the data stored in the tree.) The hash value of leaf nodes is the hash of all of their contents. In the case of the RPOW B-tree, leaf nodes hold 50 to 100 RPOW/POW token hashes, and the hash of all of these data items is the hash value of the leaf node. As you move up the tree, the hash value of an inner node is equal to the hash of the values of all of its children. Finally, at the root node, the hash of that node can be thought of as a hash of the entire tree, since the contents of every node were hashed in the process of calculating the root node hash. If you make a change to any node in the tree, its hash value will change, and the change will percolate upwards so that the hash value of every ancestor node will change, including the root node. The powerful property of the Merkle hash tree is that it is possible to produce a relatively short proof that a given leaf node data structure is actually a member of the tree, to someone who only knows the hash of the root node. This is how the RPOW server validates the behavior of the untrusted host. The basic idea is to return the entire branch of the tree that includes the leaf node, that is, the leaf node and all of its ancestor nodes, back to the root node. RPOW uses a certain way of arranging data for the Merkle hash tree that makes this highly efficient. Each inner node stores pointers to its child nodes, and along with those pointers, it stores the Merkle hash value of those child nodes. By using this data storage, it turns out that every branch of the tree has all of the information necessary to fully calculate the root node hash from that branch alone. All of the necessary hash value information from side branches is stored in the branch nodes themselves. All that is necessary for the RPOW server is to store in its memory the hash of the root node, and the depth of the B-tree. When the server needs to query if a particular POW/RPOW token has been seen before, it hashes it along with the secret prefix as described above, and then passes the result to the untrusted host, asking it to query the database and to add the item to the database if it is not already present. The host searches the tree (which is very fast since items in the tree are kept sorted) and finds the leaf node where the new item would be, or will go. It returns the entire branch of the tree back to the RPOW server. This is just a few K bytes, even for a tree which may be many megabytes in size. The host then adds the new data item to the leaf node if it is not already present, and bubbles the hash updates through the tree up to the root node, changing the root node's hash value. The RPOW server validates this response from the host by calculating the hash root of the tree based on the supplied branch. It then compares that to its own stored record of what the hash root should be. If these match, it knows that the host has behaved correctly and has returned an accurate branch of the tree. This is the fundamental property of the Merkle hash chain. The RPOW server can then check whether the looked-for data item is in the returned leaf node, and if not, it mimics the host operations of adding the data item to the leaf and bubbling the results upward through the tree, to calculate a new hash root. Fortunately, only the branch data it already got from the host is needed to calculate the new root node hash. The RPOW server can then discard the data from the host, and it will be ready to make another query when necessary. The use of a B-tree augmented with Merkle hashes allows the untrusted host to be used as a reliable place to store the seen-RPOW database. The data structure is efficient in terms of disk accesses, and the amount of data necessary to be communicated between host and RPOW server is small. The Merkle hash tree keeps the server honest and ensures that the seen-RPOW data is both accurate and up to date. The RPOW Client Software The RPOW client software is the third part of the RPOW system. This is the component which interacts with data from the RPOW server, validates RPOW certificate chains, creates and manages POWs and RPOWs. It is important for the security of the RPOW system that the RPOW client be authentic and reliable. To this end, the sha1sum of the client is published on the Download page, where you can also find an up-to-date version of the RPOW client software. An attacker who delivered an altered version of the RPOW client could perform no end of mischief, from disabling the RPOW server hash and connecting to a bogus RPOW server, to stealing POW and RPOW tokens, or even worse. Users should acquire their RPOW clients from trusted sources, or even better, get them in open source form and verify that they perform the integrity checks that are described in the Download page.