پروتکل تراکنش امنیتی قابل حمل

The Portal Security Transaction Protocol (PSTP) is a new signature technology that adds signature semantics to one-time password technology. PSTP was developed to secure transactions in the financial services industry; however, PSTP may be applicable to signatures in other spaces. PSTP technology provides high signature strength of mechanism without requiring asymmetric key pairs deployed to client machines. PSTP provides cryptographic after-the-fact evidence of a transaction event in a secured log

JPMorgan Chase Treasury Services is the largest processor of electronic funds globally. On a daily basis JPMorgan Chase Treasury Services processes on average more than USD 3 trillion in its wholesale operations. For the past five years, JPMorgan Chase used Public Key Infrastructure (PKI) [1] signature technology extensively to secure value-bearing transactions. Deficiencies with PKI-based technology impelled JPMorgan Chase to invent a new kind of signature technology called the Portable Security Transaction Protocol (PSTP) [2]. JPMorgan Chase migrated to PSTP its Treasury Services customers who interact via a web browser in order to transfer funds. PSTP was developed to secure interactive (browser-based) transactions in the financial services industry; however, the technology may apply to transactions in other industries such as health care, insurance, or legal services. The following on-line banking scenario presents an example use case. A user fills out a web-based form deployed to his or her browser. On the form, the user indicates an origin account, destination account, and monetary transaction amount. The user enters authentication credentials and presses a button marked “signature”. Next, the user uploads the form to the server. Upon receipt, the server validates the signature before processing the transaction. PSTP permits both the enterprise and the users to employ the type of authentication credential that best fits their respective needs. In general, market acceptance of asymmetric key pairs deployed to servers is good; and acceptance of asymmetric key pairs deployed to clients is poor. SSL and TLS [3], for example, enjoy wide-spread usage throughout the Internet when they use asymmetric key pairs deployed to the enterprise’s web servers; however, few users install asymmetric key pairs on their browser. This difference in PKI acceptance when comparing server and clients is not accidental. From the enterprise’s perspective, the web servers reside in locked data centers; and a dedicated staff manages the servers. The enterprise manages service interruptions through server redundancy and disaster recovery. The enterprise support staff considers maintenance of security technology to be within the realm of their job descriptions. In contrast, users do not want to be locked to a single machine. If the user’s machine fails, or if the user travels, then the user wants to simply open a browser on a different machine. The user’s job description does not normally include maintenance of security technology, and as a result the user is not willing to invest time and resources. Depending upon the relative security of the media used to secure private keying material, a PKI has two deployment choices. Unfortunately, neither choice is a good fit for the users. In the case of private keying material stored in non-secured media, (e.g., a file), the relative strength of the security mechanism is weak. Any intruder who obtains access to the non-secured media could potentially obtain a copy of the private keying material without the legitimate owner’s knowledge. Therefore, this deployment choice incurs the relatively high cost and overhead of PKI, without enjoying enough of the security benefits. On the other hand, secured media for asymmetric key pair-based hard tokens adequately addresses many of the security issues, while raising ergonomic concerns. When a user’s machine is not available, smart card [4] technology does not work unless the user can find another smart card-enabled machine. Dongles [5] and USB tokens [6] may be more portable; however, few users would be willing to correctly apply security best practices by unplugging the devices from the machines during periods of inactivity. Furthermore, despite universally recognized USB standards, smart card readers, Dongles, and USB tokens require special installation steps, and may potentially raise device conflicts. Suppose a cash manager’s company suffers penalties if the company does not make payments by the end of the day. Unfortunately, on one particular day, the cash manager has the bad luck to find that his or her disk drive crashes. When the cash manager inserts a smart card, dongle or USB token in a new machine, nothing happens because the new machine does not know how to invoke the cryptographic capabilities of the new device. Since the cash manager is not necessarily skilled in computer maintenance, he or she calls the corporate help desk looking for a solution. Hopefully, the help desk operator fixes the machine before the cash manager suffers financial penalties for the late payments. The National Institute of Standards and Technology (NIST) Electronic Authentication Guideline [7] defines four levels of authentication, each with increasing levels of security. The lowest two levels are levels one and two, and they communicate passwords through various channels. Although financial regulations do not explicitly reference the NIST classifications, one may compare to see that levels one and two are insufficient for use in Internet banking [8] and [9]. Financial regulators normally consider the equivalent of level three to be the minimum permissible level. At level three, one may use any of the following three types of tokens: (i) soft tokens that contain a shared secret encrypted by a password or symmetric key, (ii) hard tokens that require activation using a password or biometric, and (iii) One-Time Password (OTP) device tokens. For an OTP device token, “authentication depends on a symmetric key stored on a personal hardware device that is a cryptographic module … The device combines a nonce with a cryptographic key to produce an output that is sent to the verifier as a password. The password shall be used only once and is cryptographically generated; therefore it needs no additional eavesdropper protection” [7]. Each OTP device has a unique cryptographic key, and the server gets a confidential copy of this same cryptographic key. Market examples of OTP device tokens are the SecurID [10] and Vasco [11] tokens. Market acceptance for OTP devices in the financial services industry is growing, e.g. [12] and [13]. Also, the Financial Services Technology Consortium’s recent Better Mutual Authentication Project included the goal of improving the adoption of OTP technology [14]. A time-based OTP device token, e.g., SecurID, relies upon a synchronized clock shared between the client’s OTP device token and the server. At fixed periodic intervals, e.g., once per minute, the client derives a nonce from the current time, and computes an OTP value by cryptographically combining the nonce with the key. In the same interval, the server expects the client to provide an OTP value derived from the same time and cryptographic key. Generally, OTP device vendors build proprietary methods to protect against clock drift. In addition to validating the correct OTP value, the server normally implements a scheme which protects against OTP value guessing. If the server receives too many OTP value guesses in a short period, then the server temporarily suspends the client’s ability to request authentication events. A properly deployed OTP device token requires at least two authentication factors. The first factor, the OTP value, is a transient credential (TC) which is “something you have (for example, ID badge or a cryptographic key)” [7]. The second factor, is a static credential (SC) which is “something you know (for example, a password)” [7]. A user does not properly authenticate unless he or she provides both a correct transient and static credential. At level four, NIST’s highest level, NIST permits asymmetric key pair based hard tokens, but not soft tokens and OTP devices. The issue with a soft token is the lack of copy-protected media. If a user has a soft token on his or her machine, the user does not know whether an attacker possesses an illicit copy. An OTP device token suffers a different deficiency. “Like hard tokens, one-time password device tokens have the security advantage that the token is a tangible, physical object. Subscribers should know if their token is stolen, and the key is not vulnerable to network, shoulder-surfing, or keyboard sniffer attacks. Unlike soft tokens or hard tokens, a session key is not created from the authentication process to authenticate subsequent data transfers” [7]. In other words, OTP device tokens have the advantage of copy-protected storage media, but the disadvantage is that the authentication material does not cryptographically bind to data. PSTP addresses this OTP device deficiency. As a result, this paper argues that PSTP should elevate the security of an OTP device beyond soft tokens up to a level comparable with an asymmetric key pair-based hard token. PSTP is not the only solution which cryptographically binds transient credential to data. However, other solutions are either cryptographically deficient, or ergonomically impractical. A cryptographic calculator (e.g. [11]) is a handheld OTP device token that accepts input, and produces a checksum based upon the input and the transient credential. The user must type the input into the cryptographic calculator, and then read the checksum shown on a display. The user then copies the checksum from the cryptographic calculator onto a form on the user’s computer. Ergonomic considerations limit the number of characters that the user may copy from the browser into the cryptographic calculator, and the number of characters in the checksum. Users are not willing to type a long list of transactions into the calculator; and they are also not willing to copy the value of a long checksum off the calculator onto the computer. These ergonomic considerations prohibit the use of true cryptographic message digests on either the calculator’s input or output. Therefore, although the cryptographic calculator may provide some level of security assurance, the calculator cannot provide the same high level of assurance that one would expect at NIST authentication level four. PSTP is a drop-in replacement for a solution that provides asymmetric key pair based signatures. This means that the application may invoke a signature package through a common API that exports asymmetric key pair and PSTP signature syntax. One may configure the package to provide either type of signature without significantly changing the invoking application’s software on either the signer (client) or the verifier (server). The list below summarizes signing requirements shared by both PSTP-based and client-side asymmetric key pair-based signatures: • Message authentication: Using cryptographic means, authenticate the originating user of each transaction, while binding the user to the transaction’s data. • Message integrity: Using keyed cryptographic means, ensure that a transaction does not change in-transit. A transaction recipient must receive cryptographic assurance that the received transaction is bit-for-bit identical to the transaction that left the originating user’s machine. • Replay protection: Detect, and reject any occurrence of an unauthorized replay. • Consequential evidence: Provide cryptographic after-the-fact evidence of a transaction event in a secured transaction log coupled with a method for validating the after-the-fact evidence. The purpose of the validation is to justify the claim that at the time of the transaction, the message was properly authenticated, inherently possessed message integrity, and was not an unauthorized replay. • Entropy and algorithms: Observe the Uniform Commercial Code UCC4A [15] which mandates “commercially reasonable” security, by enforcing good security practices. In the case of cryptography, employ proper entropy and algorithms. Comply with US and international standards (e.g. [16], [17], [18], [19], [20] and [21]), and commercially reasonable best practices (e.g. [7], [16], [22] and [23]). • Secured media: Ensure that the mechanism permits multifactor authentication [7]. Observe regulatory guidance for strong authentication [8] and [9] by leveraging the NIST ratings for level three or level four authentication methods. A signature is not a technology that addresses all security needs. The list below presents some important security issues that are outside the scope of both PSTP and PKI signatures. Normally, applications address these concerns by deploying signatures in concert with other security technology: • Secrecy: If an application requires secrecy, then the application may encrypt the communication link using cryptographic protocols such as TLS or IPSec [24]. Alternatively, the application may implement application-layer secrecy through protocols such as WS-Security [25]. • Anti-phishing: Phishing is an attack in which an attacker fools a user into connecting to the wrong site. An application best protects against phishing by locating the mitigating control at the first point of contact between the user and the application. Therefore, most applications implement anti-phishing controls within the context of the login sequence, and as a result, anti-phishing controls are out of scope of the signing technology. Nevertheless, OTP technology thwarts many of the most common phishing attacks. If the user enters an OTP into a malware-infected machine, then the machine may potentially use the OTP in an unintended manner. However, the machine cannot solicit future OTP values from an OTP device token without the user’s knowledge. • Receipts: An application may potentially employ signing technology as the vehicle for securing transaction receipts. However, a receipt is a particular use of signing technology; and is not an inherent aspect of the technology itself. • Denial of service protection: An application may use firewalls, intrusion detection, and intrusion prevention to protect against denial of service attacks. These controls are important to an application’s security, but are not the responsibility of the signature technology. This paper provides a comparison of the terms consequential evidence and non-repudiation. This paper has the position that the term non-repudiation has meaning which should have remained insular within the cryptographic community. However, common practices mistakenly apply the term non-repudiation to a greater context, where the cryptographic meaning of non-repudiation has little importance from either a legal or business perspective [26]. The binary concept of cryptographic non-repudiation, for example, ignores the crucial issues associated with the media that holds the confidential keying material. In contrast, as opposed to a binary property, consequential evidence is a control with an inherent strength of mechanism metric. This metric takes into account cryptographic assurances, cryptographic key protection, logistics security, and possibly other measures. As in the case of most other security technologies (e.g., authentication, intrusion detection, etc.) one may assess the relative level of assurance provided by the security technologies, and then compare. From this perspective, PSTP compares favorably with PKI. The purpose of this paper is to define a signature technology that deploys asymmetric key pairs to its enterprise servers without requiring users to accept their own asymmetric key pair credentials. If a particular market is unable or unwilling to accept asymmetric key pairs on the client machines, then PSTP provides an excellent signature technology. The organization of this paper is as follows: Section 2 presents a high-level summary of PSTP that overviews the mechanism. Section 3 presents an example deployment. Section 4 presents an analysis and a consequential evidence comparison between PSTP and PKI. Section 5 presents related work, and Section 6 is the conclusion.

The comparison between PSTP-based signatures and PKI-based signatures is complex. Both technologies provide similar functional characteristics (e.g., message authenticity, integrity, replay protection, and consequential evidence). When deployed using properly secured token media, both technologies adequately protect confidential keying material. From a purely cryptographic perspective, a PKI has an advantage because the server has no access to the client’s confidential keying material. At first glance, this advantage provides the appearance that a server cannot forge a valid signature on a client’s behalf. However, this appearance is merely a façade. The timestamp server can create a signature using a compromised asymmetric key pair, and change history by moving the signing date so that it precedes the date that the asymmetric key pair first appeared on the revocation list. Other nuances in a PKI’s Certificate Authority also exist which further degrades the cryptographic advantages of a PKI. PSTP enjoys some advantages over PKI technology from a security perspective. Since an OTP inherently requires user interaction, malware on a user’s machine cannot sign without the user’s knowledge. When one takes into account all of the characteristics of PSTP and PKI, both technologies provides excellent security. However, both technologies have caveats and nuances that render a comparison of strength of mechanism difficult to quantify. One should view PSTP as an alternative to PKI, as opposed to a general-purpose replacement. Straight-through processing which requires no explicit human interaction is a better candidate for PKI than PSTP technology, because no one would be available to copy the OTP token value from the OTP device token to a computer. Furthermore, the administrators of both peers in the straight-through processing system should have the ability and motivation to handle an asymmetric key pair. A browser-based use case, on the other hand, is more suited for PSTP. An OTP device token’s lack of electronic connection between the user’s machine and the OTP device token has installation, mobility, and security advantages. PSTP signatures, paper-based signatures, and PKI-based signatures all have inherent costs. Whenever the cost of PSTP signatures is the least of the three methods, PSTP may provide the most viable solution. The clearest examples are environments that already deploy OTP device tokens. The financial service community is a good candidate because the high risk of financial transactions induces the financial community to use strong security. A second candidate is a corporation that deploys OTP device tokens to its employees so that they may remotely login through a VPN. Since the employees already own OTP device tokens, the enterprise may dual-purpose these tokens for PSTP signatures. So, for example, when the employee needs to sign an internal corporate document, e.g., change tax withholding status, then employee may use his or her OTP device token for the PSTP signature. Another use for PSTP is to business process re-engineer a paper-based environment. Consider, for example, a court document submission which requires a series of signatures. If the cost of handling the paper exceeds the cost of deploying an OTP device token, then PSTP may be a good, cost-saving solution. JPMorgan Chase Treasury Services successfully deployed PSTP technology for browser-based wholesale financial transactions. JPMorgan Chase dropped in PSTP software as a replacement for PKI software without significantly changing its applications’ programming logic. This successful deployment provides evidence that PSTP is a viable, currently available technology.