One of the recurrent problem in electronic transaction security is the threat of "bogus terminals," an example of which is a POS terminal with a bank label and the look and feel of a legitimate POS terminal, but actually operated by a defrauder. The transactions are rejected because the bogus terminal is not connected to the financial network, but the defrauder may intercept the account holder PINs before the account holder becomes aware of the rejection, which may be attributed to a technical failure.
With the growing use of personal computer software for electronic transactions, the bogus terminal threat could materialize if someone downloads a bogus software application from a server without being aware of the sham. For instance, a defrauder may change the electronic mail address of the financial institution in the bogus software application. Then, the account holder would prepare a complete financial transaction, including the secret PIN, and the transaction details would be sent to the defrauder's mailbox.
With the further development of a public key infrastructure for electronic transactions, the concern about bogus software applications does not vanish; it turns into a concern about integrity of the public key for the "top-level certification authority". For instance, the look and feel of a bogus software application would not allow the account holder to detect if the top-level public key would have been changed to one chosen by a defrauder. The bogus software application would obtain a false chain of security certificates prepared by the defrauder using the bogus top-level public key. As a consequence, the financial transaction would be sealed and encrypted for the defrauder instead of the financial institution.
The desirablility of the proprietary approach is hinted by Matt Blaze in his afterword to the book by Bruce Schneier, on page 620, where he confirms that "modern computers aren't especially good at protecting even the smallest secrets," this being the number 3 among the "Top Ten Threats to Security in Real Systems."
For to lessen the threat of bogus terminals, the typical countermeasure is to control the distribution of complete terminals (and parts, materials, and technical data used to make terminals) with the very look and feel that puts an account holder in confidence to enter a secret PIN. The same strategy should be used with software applications: serious software publishers should tightly control the issue of new releases to prevent bogus releases by defrauders. Thus, the critical data for which integrity protection is needed should be embedded in the software application in a way known by as few persons as possible.
Bogus terminals may also be operational terminals modified by a defrauder, either after being stolen, or legally obtained and then diverted from legitimate usage. Thus, it becomes important to increase the difficulty of reverse-engineering. One way to do this with software is to encrypt and seal critical data, so that it is available in clear form only within the computer memory and when in use. But then the cryptographic keys used for encryption and sealing becomes the critical data, so the reverse engineering threat is set back rather than eliminated. Then, it may look sound to use a proprietary algorithm to do the encryption and sealing, with a proprietary cryptographic key structure. The problem with proprietary cryptographic algorithms is that their design lack the critical review of expert cryptanalysts.
The desired security is to ascertain that a set of data (e.g. the contents of a configuration file) is unmodified and used only by a software program released by a given organization. With the proprietary approach, the security is based on
It would be useful to reduce the level of skills required for the design of proprietary cryptographic schemes. This is where the Frogbit algorithm is attractive: the overall structure of the algorithm is well defined and publicly reviewed, but an important quantity of implemantation details are left open for private customization. Specifically, the customizable part comprises ten independent pseudo-random generators. The specialized literature contains many designs for pseudo-random number generators. See the document entitled "The Frogbit Semi-Proprietary Scheme" for instructions on using this scheme.
CONNOTECH Experts-conseils Inc.
9130 Place de Montgolfier
Montréal, Québec, Canada, H2M 2A1
Tél.: +1-514-385-5691
Fax: +1-514-385-5900