Comments on "Building Confidence in Electronic Commerce" ******************************************************** By Charles Lindsey ========================================= 5 Clerewood Avenue Heald Green Cheadle SK8 3JU Tel/Fax (0161) 437 4506 Date: Wednesday March 31 1999 +++++++++++++++++++++++++++++ The Document to which I shall refer is o Building Confidence in Electronic Commerce, a consultation document published by the DTI (URN 99/642) on 5th March 1999. I am a retired Senior Lecturer in Computer Science at the University of Manchester. Since my retirement, I have made it my business to take a detailed interest in many activites related to the Internet, including in particular matters connected with the authenticity and security of digital communications. 1. Technical inadequacies contained in the Document. ==================================================== It would appear that the DTI have been badly advised as regards certain technical features concerning digital signatures and encrypted communications, leading to some inappropriate wording in the Document. It is essential that these errors be corrected when it comes to drafting the Act, and any regulations that may be made under it. I give various examples below. 1.1. Key Generation for Digital Signatures. ------------------------------------------- The Document rightly recognizes that key generation is a critical part of the process, since a key produced by inadequate means (whether through ignorance or malice) opens up the possibility for signatures to be forged. It is therefore much to be regretted that the Document then appears to give assent to practices which are totally at variance with current "best practice" in this matter. Specifically, in Annex A(II) under criteria for CAs: A provider will need to submit details of how an asymmetric key-pair is generated and ... delivered to the client. If the key-pair is to be clientgenerated then details of the process used will need to be supplied. ... An applicant must provide details of the mechanism it uses to ensure that the private signature key is only known to the client on issue. Contrary to what is implied there, a proposal by a prospective CA to do any of the things suggested should be grounds for the REFUSAL of a Licence. Let us be clear what current 'best practice' is. Key Pairs (especially for signature) MUST be generated by the client, preferably on his own equipment, or on board his recently-purchased smart card (and if he is really paranoid, on his own laptop in the middle of a large field away from all possibility of Tempest surveillance). The generated key must NEVER be in the possession of any other party. The algorithm used MUST be in the Public Domain, and he MUST be able to use a program or device of his own choosing. For the one who controls the key generation (especially the one who wrote the key generation program) is the one who can later forge the signature, and moreover there is no way to tell, by subsequent examination of the key, whether or not it was generated by such weak or fraudulent means. Furthermore, the presumption in Annex A(II) that key generation is related in any way to certification is fundamentally flawed. The normal situation will be that the key is generated BEFORE being brought to the CA. Indeed it might be submitted to more than one CA, and when the certificate expires it might be taken to a different CA for renewal. That is not to say that CAs will not regularly provide advice and facilities regarding key generation, and indeed offer many other services, but that should arise out of a separate side of their business. The worst possible practice would be for the key generation to be performed by the party that expects to receive documents electronically signed with it (one hears horror stories of banks and credit card companies who fondly imagine that they could do just that). For this reason, I recommend that the Act should stipulate that the party that generates a key is explicitly excluded from relying in court upon signatures made with it. 1.2. Approval of systems and devices. ------------------------------------- In connection with the legal recognition of digital signatures (#20) the Document refers to "approved" signature creation devices (this presumably refers to smart cards and the like - the lack of mention at this point of signatures produced on ordinary PCs is surprising), and again (Annex A(II)) to "approved" signature generation products. Yet the machinery for "approval" is not specified, beyond a reference (footnote 13) to some incomplete work within the EU. Whilst the need for such approval machinery is evident, and the fact that it is intended to be uniform across the EU is welcomed, it must also be stated that the ONLY credible method for ensuring that cryptographic products meet their stated objectives is for the underlying algorithms and source code to be in the Public Domain, so that they can be scrutinized by a substantial community of independent experts worldwide. It cannot be emphasised too strongly that it is ONLY by such independent scrutiny that it can be assured that a product is free from hidden features which enable those "in the know" to forge signatures made with it or decrypt messages encrypted with it. Hence my insistence above that algorithms for signature generation, in particular, MUST be in the Public Domain and MUST be at the choice of the user. I would rather have a signature generated by an unapproved and less-than-perfect program than one generated on my behalf by a CA using the pig in his poke. 1.3. Requirements for legal recognition. ---------------------------------------- The wording of the Document concerning legal recognition of signatures (#20) provides evidence of some very woolly thinking. It speaks of "an electronic signature issued by a licensed Certification Authority" whereas licensed CAs are not in the business of issuing signatures (it is their clients who do that). What CAs issue is certificates. Again, it matters not (to the Court) whether the signature was produced by "an 'approved' signature creation device" or not - if the signature exists and verifies it could only have been produced by that client - though the Court should indeed care that the signature METHOD (i.e. the algorithm) was approved. There is no way that a valid signature could be produced "accidentally" by any device, approved or not. What the Court needs to be told is: a) That the signature method (or algorithm) used was approved. b) That the electronic document exhibited was signed by a certain Key in accordance with that method. c) That the electronic certificate exhibited associates the said Key with the Individual alleged to have signed the document d) That the said electronic certificate was issued and signed by a licensed CA (and that, by the same tests, the CAs signature on the certificate is good). In the case of a Qualified Certificate, the Court needs to enquire further into step (d). But observe that in neither case is the approval or otherwise of the signature creation device of any relevance, contrary to #20 of the Document. Such approval is, of course, of extreme concern to the Individual; but the use of an inferior smart card (containing a not-so-secret key), or his allowing the card to be used by someone else, or disclosing his passphrase to someone else is his problem, and it is useless for him to protest that he has been defrauded, except when the alleged defrauder is the party trying to rely on the signature (see my recommendation above in that regard). There is, however, one serious situation not covered by the Document (but hopefully to be addressed by the EU Directive) which is where an individual is expected to attach his smart card to some apparatus (a check out till) in order to sign away the sum of money displayed on the till. How is he to know that the electronic cheque passed into his smart card for signature is for the amount displayed on the till? He isn't. Maybe the till is "approved" as genuine by some official body (maybe that is the situation #20 had in mind, but note that the till is not a "signature creation device", so that section is still badly worded). As for me, I would not trust my smart card to such a device. 1.4. Private Keys vs Session Keys. ---------------------------------- The Document uses the term "Key Recovery" in a most confusing manner (as is indeed admitted in Footnote 17). There are two cases to consider: 1) Key Storage or Key Escrow, where the PRIVATE key of a key pair is stored in a safe place (whether with some TTP or otherwise) against some foreseen catastrophe (see #36). 2) Key Encapsulation, where the SESSION key of each encrypted text is itself encrypted with the public key of some Key Recovery Agent (which again may or may not be a TTP). The Document, whilst admitting that the term "Key Recovery" is widely used in both senses, uses it only with the 2nd meaning. This has undoubtedly caused difficulties for those reading the document who have not spotted this crucial distinction on their first reading (nor even on their second or third reading). Let us review the two cases, bearing in mind especially the consequences of the recovered key falling into the hands of a third party (whether that be lawful, as with warranted access by a LEA, or otherwise). 1) If Alice's key is "Escrowed", then it is her PRIVATE key that is stored away, and then perhaps revealed to the LEA upon production of a warrant. The LEA is then enabled to decipher ALL messages sent TO her BY Bob, both in the past and indefinitely into the future, but NOT those sent BY her TO Bob. This could severely compromise the future security of Alice's whole business. Why she should entrust her key to a TTP when she could store it in house is totally beyond me. 2) If a key is "Encapsulated" (for which the misleading term Key Recovery is used in the Document), then it is the SESSION key of each of Alice's individual messages which is encoded with the public key of a KRA. So Alice can find out exactly what messages her employees have been sending (or storing on disc), and so can the LEA armed with the proper warrant served upon the KRA. N.B. this time it is the messages sent TO Bob BY Alice that can be recovered, NOT the ones sent BY Bob TO her. A benefit (to Alice) of this method is that (the header of) each message has to be submitted to the KRA to have its session key recovered, and so messages outside of the time span of the warrant are not at risk. Of course, that benefit falls flat on the ground if the LEA is entitled to demand the KRA's own private key, but the document seems to imply that the amended IOCA would not confer such entitlement (though #69 is not entirely clear on this matter). But why Alice should employ an external KRA to perform this service for her when she could equally well do it in house is, again, totally beyond me. Note the vital difference in the nature of the key that is recovered in the two cases. Indeed the failure of the Document to distinguish between Private Keys and Session Keys is a major failing. A further instance of the confusing terminology of the Document is the reference to access by LEAs to "encryption keys". This error occurs in no less than 14 places in the Document (#3, #11, #12, #13, #37, #49, #58, #62, #63, #64, #65, #74, #78, #79). When a Public/Private key pair is used to encrypt a message, knowledge of the "encryption key" is of no use whatsoever to the LEA (it is simply the Public Key). What they require is the "decryption key", which is secret. If the Act itself is worded in such a sloppy manner, it will in fact be meaningless. OTOH, if these 14 references are to the Session Keys, then they do make sense, insofar as a Session Key is symmetric, being used for both encryption and decryption. As to whether this unfortunate terminology is merely a drafting error, or whether it indicates a fundamental misunderstanding of the encryption process by the DTI is not clear. In #80 it refers to a notice "served on the individual in control of the encryption process" who will, in general, be unable to help (unless, again, it is Session Keys that are being referred to, and even then the individual in control of the encryption process is unlikely to have retained the Session Key, and cannot recover it without the Public Key, which will not in general be known to him). It may be possible for that individual to assist in the case where Key Encapsulation had also been used, but that is unlikely to be the common situation. 2. Access by Law Enforcement Agencies. ====================================== 2.1. Warrants for access to keys. --------------------------------- The promise in the Document (#64, #67, #69, #73, #74, #77, #80) that warrants for access to keys will be by "written notices" is welcomed, and is a considerable advance on the electronic notices envisaged by the 1997 document. Moreover, the idea that persons in possession of keys that would enable decryption of communications should be required to cooperate with LEAs is broadly accepted. 2.2. Protection of innocent parties. ------------------------------------ The recognition (#87) that it will frequently be necessary for LEAs to seek assistance from (presumably innocent) corporate bodies with whom a criminal may be communicating, and that such cases will require different treatment, is welcomed. However, that paragraph is rather vague insofar as it seems to imply that such corporate bodies will be expected to provide such assistance voluntarily. This is not good enough. No such corporate body, which has a duty of confidentiality towards its clients, is going to provide assistance without some piece of paper from some Proper Authority to cover itself over such a breach of its duty. On the other hand, a full warrant as it seems to be envisaged by the Document would be a huge overkill in this situation; in particular, there is no reason whatsoever why a party in this situation should be required to hand over its Private Keys in response to such a warrant. For that would compromise its communications with large numbers of its existing clients over an extended period of time, and require it immediately to change all those key-pairs at inordinate expense and at great disruption to its business (the idea that the Corporate Body would be content to rely on any assurance given to it by the LEA concerning the limited use of such keys, or of their subsequent destruction is risible). Thus the Act MUST provide that a warrant issued in these particular circumstances (indeed, in any case where a warrant is served upon an innocent party) would only require the party concerned to provide Plaintext or Session Keys for given communications in a timely manner, and to refrain from "tipping off". Here again, the importance of distinguishing between Private Keys and Session Keys is to be noted. 2.3. What may a warrant require to be done? ------------------------------------------- The Document currently proposes (#69) that it is for the warrant (or even the officer in charge of the particular case) to specify whether the required material is required to be produced as Plaintext, or as a Session Key, or as a Private Key (except that it does not, as usual, distinguish between the latter two, but it should). This is already unacceptable in the case where a warrant is served on an innocent party, for reasons outlined in the previous paragraph, but I would suggest that it is actually unacceptable in all cases. Why should the LEA ever require the Private Key, assuming that the party concerned is happy to provide Plaintext or Session keys in a timely manner? It could be argued that the LEA might not want the party to be aware of what plaintexts were being examined, but it would suffice in that case for them to request the production of Session keys (note that it would not be necessary for them to provide the complete cyphertext in that case - the header containing the the encrypted Session Key would suffice - so that the party concerned would not be able to recover the plaintext for himself). Furthermore, even if Plaintext is offered, the LEA still needs to be sure that it matches the Ciphertext, and to verify that it really needs to see the Session Key. Thus provisions of Sessions Keys would appear to be the appropriate method in nearly all circumstances. Note that timely provision of Session Keys would also be particularly appropriate where a warrant was served on a licensed TTP who was in possession of the relevant keys, for then it would make good sense for him not to see any plaintext and, moreover, he is in the position of being required not to "tip off". Where the warrant is served on a suspected party, such procedures are less important, because he is presumably already aware of the Plaintext. It also needs to be clarified whether an employer (perhaps a largish corporation) is required to avoid "tipping off" an employee whose communications are being intercepted, but where the communications in question relate to the employer's business. 2.4. Proportionate measures. ---------------------------- There is a welcome reference in the Document (#11, #12, #13) to measures that are "proportionate". There is one particular situation where this principle could be applied, and that is the urgency with which those served with a warrant are required to respond (and particularly where it has been arranged that they are to supply Plaintext or Session Keys in a timely manner on demand). If you are following a money-laundering operation, then milliseconds are important. If terrorists are planting a bomb, then you are concerned about minutes. To catch drug runners, you need your information within hours, and when tracking paedophiles, it does not really matter if you have to wait days. It should therefore be possible for the format of warrants to permit variations in such requirements in order to suit the circumstances of the particular case. 2.5. Alternatives to Escrow. ---------------------------- The Government has asked for further suggestions as to how encrypted communications from criminals could be monitored without requiring Private Keys to be escrowed compulsorily (an unworkable proposition in any case). I have one suggestion to offer. It is the case that much of the traffic that LEAs will want to monitor will relate to financial traffic in connection with money laundering, which usually involves moving substantial amounts of money rapidly between assorted Bank accounts, and often across international frontiers. The LEAs already have the authority, under the Bankers Books Evidence Act 1879, to examine bank accounts, but in the circumstances mentioned many horses would have bolted by the time the paperwork accessible under that act had caught up with the actual events. However, it could perhaps be possible to amend that Act so as to permit warranted access to electronic transactions to or from named accounts to be obtained in real time - as those transactions happened. This could even be preferable to monitoring and decrypting the communications whereby those same transactions were effected, since transaction in both directions (debit and credit) could be observed and correlated together. 3. The Licensing Agency. ======================== It is noted that OFTEL is likely to be appointed as the licensing agency. This is all right so far as it goes, but it needs to be pointed out that OFTEL currently has no expertise in cryptography, and that it will be essential for people with that expertise to be hired, since the licensing process will inevitably raise many issues of a very detailed technical nature. However, the arrangements to be made are only sketched in the Document, and there are therefore many specific issues which need to be addressed before this matter can proceed further. 3.1. Terms of Reference. ------------------------ As clearly stated (#41) the licensing framework needs to be trusted by all sectors of industry, especially when it comes to setting requirements to be met by licensees. Such requirements will be technical in nature, ensuring that licensees adopt practices which are widely accepted as "Best Practice" within the field. However, there may also be requirements of a more political nature. To take a specific example, we find in Annex A(II): An applicant will need to demonstrate that the certificates it issues have all the following information: ... * an unambiguous statement that the certificate must not be used to validate a key being used to secure the confidentiality of information; Now there is no technical necessity whatsoever for that restriction. The requirement is purely political. And if the Licensing Agency is involved in political decisions, then it cannot possibly inspire confidence in those whom it is meant to serve, namely the industry and the users of cryptography. Therefore, its terms of reference MUST be strictly to decide all matters on their technical merits. If there are political requirements within which they have to work, then these should be set out explicitly within the Act, or perhaps in Regulations made in accordance with the Act. Whilst that particular section of Annex A(II) is in view, let me also take exception to its wording. The format of certificates (which are invariably in electronic form) is subject to standardization by various International Standards bodies (e.g. ISO and the IESG). Therefore it may be technically impossible to meet the requirements as stated. In particular, there exist standard forms of certificate which do not specify whether the key may be used for signature or encryption but rely, instead, on a field within the key itself to convey this information (thus effectively achieving the same thing). The wording needs to be modified to take account of this; however, this is a prime example where drafting requirements without full technical knowledge of the issues involved can bring the whole scheme into disrepute. Recall the statement in the Document (#3, #16, #23, #42, #52, #66) that this new law is supposed to be "technology neutral". It should also be noted that this particular restriction is rather pointless insofar as there are a variety of techniques whereby it may be legally circumvented. 3.2. Form of the Licensing Agency. ---------------------------------- To achieve the principles set out above, I would therefore suggest that the Licensing Agency should be in the form of (or at least delegate the bulk of its day-to-day operations to) a "Licensing Board" composed of Government and Industry representatives - a Quango that is seen not to be totally under Government control. It also needs to be made clear that its duty is towards the users of cryptography (which includes the general public), not towards those who supply cryptographic services and products. 3.3. Approval of Products. -------------------------- It appears that approval of products (for example, in order that signatures made with the product may be legally recognized) is to be handled under separate machinery to be established in accordance with the EU Electronic Signatures Directive (the Document is distinctly vague in this area). In that case, much of what I have said above with regard to the Licensing Agency would apply to that machinery also. In particular, it should not be supposed that suppliers of cryptographic products will necessarily be large corporations with large budgets able to afford large fees to the Licensing Agency (for indeed the best cryptographic products often arise from cottage industries). Indeed, it might well be proper for no fee to be charged for the approval of products (in particular, programs) that were to be placed in the Public Domain and provided for free. 4. Summary of Recommendations. ============================== 1. (1.1) The Act should strongly discourage, if not actually forbid, the generation of a Public/Private signature key pair by other than than the person who is to be committed to that signature. 2. (1.1) The party that generates a Key should be debarred from relying in Court upon signatures made with it. 3. (1.4) LEAs should not have the right to demand the Private Keys used for communication with their clients by CAs, TTPs and KRAs except where those bodies are themselves suspected of malpractice. 4. (2.2) The Act, and the Regulations made under it, must make a clear distinction between Private Keys and Session Keys, especially as they relate to powers to be granted under a warrant. 5. (2.2) A warrant served upon a corporate body (or indeed on any innocent party) should give that body the option of providing Plaintext or Session Keys as opposed to revealing Private Keys. 6. (2.3) The previous recommendation should in fact be extended to all parties upon whom a warrant is served. 7. (2.3) It should be clarified whether the prohibition of "tipping off" should apply between an employer and his employees. 8. (2.4) The time allowed for filling the requirements of a warrant should be proportionate with regard to the actual urgency of the particular case. 9. (2.5) Consideration should be given to amending the Bankers Books Evidence Act 1879 (in addition to the IOCA and the PACE) as providing an alternative to Key Escrow in some important cases. 10. (3.1) The Terms of Reference of the Licensing Agency must be to decide all matters on their technical, rather than political merits. 11. (3.1) The proposed requirement concerning validation of confidentiality keys by CAs should permit that information to be contained in the key itself, rather than in the certificate. 12. (3.2) The main work of the Licensing Agency should be delegated to a Licensing Board composed of Government and Industry representatives. 13. (3.2) The prime duty of the Licensing Agency must be towards the users of cryptography (i.e. the general public) rather than towards the suppliers of cryptographic services and products. 14. (3.3) The recommendations made above with respect to the Licensing Agency should also apply to whatever body is responsible for approvals under the EU Electronic Signatures Directive. 15. (3.3) Fees should not be charged for approval of products which are placed in the Public Domain, and provided free. 5. Conclusion ============= It is hoped that the above recommendations will be helpful to the DTI in progressing these matters further. I should be happy to provide clarification, or to discuss details of these suggestions further, or to provide any further assistance that might be of help.