-----BEGIN PGP SIGNED MESSAGE----- Comments on the Draft Electronic Communications Bill **************************************************** By Charles Lindsey========================================= 5 Clerewood Avenue Heald Green Cheadle SK8 3JU Tel/Fax (0161) 437 4506 Date: Friday October 8th 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. There are many features of this Bill which have attracted widespread adverse comment, with most of which I agree. I have, however, chosen in these Comments to address just a single issue - namely the section 10 notices, that which they may contain, and the manner of complying with them. It is my opinion that the Bill, as presently worded, deprives those who receive the notices of some basic rights, whilst at the same time omitting some features which would be of benefit to the Law Enforcement Agencies. I start with Section 19, which defines some basic terms, and then proceed to discuss sections 10 and 11. Section 19. +++++++++++ The definitions of "signature", "key" and "protected data" in this section give cause for concern. In particular, it is not recognised that electronic signatures may be used for conveying permission to perform some act. This is done by constructing some token which conveys the permission and signing it with the private key of the person claiming to have authority to give that permission. Examples of the permissions that might be conveyed in this way are permissions to access (or rather to use) some other key (whether it be an encryption or a signature key), and for delegating authority for the giving of some permission to someone else. For example, the Company Accountant might be authorised to make payments using some form of electronic funds transfer, by creating a token containing details of the transfer and giving permission for the corporate fund-transfer-signing-key to be used to authenticate the transfer. He would sign the token with his own private key so that the central secure computer that actually generated the signed transfer could check that the token came from a properly authorised person. More likely, he would delegate authority to make such transfers (perhaps up to some defined limit) to some member of his staff (and revoke that authority also, as occasion demanded). Likewise, his own authority would have been conveyed to the central computer by some token signed by the Managing Director, and the Managing Director's authority would have been signed by all the other Directors, and so on - presumably the buck stops somewhere. But notice in particular a) That long chains of authorizations can be built up in this way. b) That the keys used to sign these tokens are just the ordinary private signature keys of the individuals concerned. c) That the tokens are not "protected information". Their content is no secret; it is just that the central secure computer has been programmed not to act upon them without the proper signatures. This sort of complex system is likely to be prevalent within large organisations where many people may have to generate signatures or to decode documents using the Company's corporate keys, which necessitates keeping them within some secure central computer within which the signatures or decryptions are actually performed. Such systems will also be used by those Approved Providers who choose to offer a Key Escrow service. In all such cases, the corporate keys will remain at all times within the central secure computer (they were likely even generated there) and will only be extractable from same with extreme difficulty, if at all. Although the keys used to sign these tokens are clearly "signature keys" under the bill as presently worded, this matter is of sufficient importance that this usage needs to be recognised in the text. I therefore propose that part (c) of the definition of "electronic signature" be amended to read as follows: (c) is used for the purpose of facilitating, by means of a link between the signatory or other source and the data, the establishment of the authenticity, or the integrity, or the authority conveyed by, the data, or any combination of these things; Given the strong promises made by the Government that "signature keys" would not by subject to enforced disclosure, it is unthinkable that the Bill should make any exception for signatures used to convey permissions as outlined above. Nevertheless, this seems to be precisely what the Bill as currently drafted purports to do. Consider the definition of "key" which follows immediately after that of "electronic signature". Firstly, the definition is circular, insofar as it says that a "key" means, inter alia, a "key". More worrying is the use of the word "password". Passwords, as normally understood, are not used for encryption, nor for signatures. Rather, they are used for gaining access to some facility. But the real sting is part (a) of the definition which declares that a "key" can be anything which "allows access to the electronic data" and, clearly, that covers the sort of signed token that I have described above (it gives access to the keys stored in the central secure computer), or more particularly the signature keys used to sign such tokens. This, of itself, would not be of concern were it not for Section 11(2)(a) which allows for a person to obtain access to some protected information using a key in his possession, BUT specifically requires him to deliver up that actual key if so "directed" in accordance with 11(3) even though that key is likely to be a bona fide signature key being used in the manner I have described above. This situation is quite intolerable. However, I think this problem is best fixed in Section 10 or 11, for which see my proposals below. Finally, the definition of "key" makes no mention of signatures, even though the term "signature key" is used elsewhere in the Bill. So I therefore propose that the definition of "key" be reworded as follows" "key", in relation to any electronic data, means any code, phrase, algorithm or other data the use of which (whether or not in conjunction with other keys)- (a) allows access to the electronic data, or (b) facilitates the putting of the data into an intelligible form, or (c) serves to establish the authenticity, or the integrity, or the authority conveyed by, the data; Having said that, I see no reason why the Bill needs to concern itself with access to data at all. If there is data which is not encrypted (it is already in intelligible form) but is inaccessible simply because the password (or other more complex security feature) that would gain access to it is not known, then surely all the LEA has to do is to seize the whole computer under warrant and take it to pieces. Faced with the choice between having one's computer seized, as opposed to giving up one's password and keeping the computer, the average user would doubtless give up the password willingly. So I would therefore prefer to see paragraph (a) removed from the above definition entirely, along with the corresponding paragraph in the definition of "protected information". Section 10. +++++++++++ The drafting of this and the following section leaves much to be desired. Basically, it fails to take account of the realities of cryptography as currenty used, let alone of possible ways it may develop in the future. Thus it places some unacceptable burdens on some people, whilst at the same time failing to provide the LEAs with some of the benefits they might have expected to have. The major failings I will deal with under Section 11, but in the meantime there are various lesser matters which affect Section 10, the first of which is the confusing terminology whereby the word "person" is regularly used, even within the same paragraph, to refer to: (a) The "person" who has acquired a copy of the protected data by some statutory or other means (subsection (1)). (b) The "person" with the appropriate permission to serve a notice. (c) The "person" upon whom the notice has been served. I propose that most of the confusion can be removed by using the word "officer" to cover case (b), both here and in Schedule 1, and my further proposals below are worded on that assumption. subsection (2): This needs to recognise that there may be several keys involved with access to the protected data, that they may be in the possession of several persons, and that some of them may need to be derived by possibly complicated processes. My proposed ammendments are p10 line 1 any person => any officer line 2 a key to the protected information => a key or keys to the protected information, or the means wherewith to derive such keys line 3 any person => any person or persons line 4 person => officer line 5 possession of the key => possession of such a key line 5 disclosure of the key => disclosure of that key subsection (3): Paragraph (a) seems to envisage notices being delivered by electronic means, and seems to be based on the idea that "proof of posting" is equivalent to "proof of delivery". That is grossly unfair. It must be possible for the officer to prove that the notice has been received in much the same way that the serving of paper documents currently reuqires proof. Another problem is the time allowed for compliance with the notice. It is no use the officer serving the notice and saying "right, you now have 5 minutes, or you will be charged under Section 12". For the reasons I have outlined earlier on, it may take hours, or even days, to comply in some situations. My proposed ammendments are p10 line 10 given => given and received p10 line 12 person => officer p10 line 14 to be made => to be made, such manner and time being reasonable having regard to the technical difficulties of performing the disclosure It is not stated how the noticed is supposed to identify the required key, and this is particularly important in the case where several keys may be involved, such as an asymetric private key and a session key. The only way to identify the key is to provide the person with the protected data (if he does not already have it). Or, if he does not have it and the officer does not want him to be in a position to retrieve the plaintext, then at least a sufficient part to enable the session key to be extracted. I would therefore propose an additional paragraph (d) (d) must, unless the protected information is already in the possession of the person receiving the notice, incorporate that protected information; or at least a sufficient part of it to enable the person to identify all of the keys involved; or else, in the case where the notice refers to information likely to come into the possession of any person in accordance with paragraphs (a) and (b) of subsection (1), sufficient information to identify the class of protected data to which the keys are, or will be, required. subsection (4) p10 line 17 person => officer subsection (5) This is an important safeguard, which has been guaranteed by the Government. Nevertheless, there exist keys (notably PGP keys generated by earlier versions) which the user now uses only for signature purposes, but had once used for encryption many years ago. Or since, with some keys, it is impossible to prevent them from being used for encryption, someone might send him a message encrypted with it, so as to embarass him. It is hard to see how to deal with this entirely, but at least it should be incumbent upon the LEA to prove that a supposed signature key was in fact being used for encryption, and for sure the fact that it had only been so used long before the present circumstances arose should not provide an excuse for the LEA to demand a signature key, as the present wording clearly allows. I propose, at the least p10 line 24 has not in fact been used for any other purpose => is not in fact currently in use for any other purpose There is a further problem in that private keys (whether for signature or encryption) are customarily stored on the user's computer in encrypted form, and he needs to provide a "passphrase" in order to decrypt them whenever he needs to use them. It was clearly the intention of the Government's guarantee that a user should not be compelled to divulge either his private signature key, or the passphrase that protected it. Nevertheless, in the case where the (passphrase-encrypted) private signature key has come into the possession of the LEA (by seizure of the computer under warrant, for example) the Bill, as currently drafted, would allow the officer to demand the passphrase. For the encrypted signature key is clearly "protected data", and hence the officer can demand the key to put it into intelligible form (i.e. the form in which it could then be used to sign documents). Clearly, this is intolerable. Furthermore there is the loophole which I identified above when discussing signed tokens. I therefore propose an extra paragraph (c): ...; or (c) where the protected information to which the key relates is or contains a further key which is not itself the subject of this or any other notice. Section 11. +++++++++++ The wording of this section is convoluted and full of double negations, it contains a right to direct that actual keys be provided even when the person is willing and able to provide timely decryption into intelligible form, with absolutely no restrictions on the exercise of that right, and it is couched in terms that are only applicable to the simplest and most straightforward cases of encryption, such as were commonplace 10 years ago, but bear no resemblance to the sophisticated and complex systems which are encountered today, and still less to what may be found in the future. Thus this section does not provide the LEAs with the powers that they actually need, not does it provide the owners of the keys with the protection that is their due. It cannot be overemphasised how serious it would be for a large undertaking, such as a bank, to have its main corporate encryption keys seized. The costs to the Bank would run into millions. It is useless to argue that the seized keys would be in safe hands as set out in Section 15. No corporate executive in his right mind would place any credence in such promises, especially given the knowledge of the collusion of the UK in the Echelon project. But this is not all bad news. A bank faced with the prospect of losing its keys would be willing to fall over backwards in an effort to provide all assistance to the LEA short of actual disclosure. The Bill should be worded so as to give the LEAs full benefit of such willingness. The basic fallacy of the present Bill is that it keeps speaking of "the" key to the data, and fails to recognise that (a) There may exist several alternative keys ANY ONE OF WHICH would suffice to access the protected information. This arises particularly where the information is first encrypted with a transient "session key", which is then itself encrypted with the user's private key. Since the compromise of the latter would be disastrous for the user, he must have the absolute right to choose to disclose only the session key. Other cases of multiple alternative keys arise when an encrypted communication is addressed to several people. (b) There may exist sevral keys ALL OF WHICH (or, at least, several of which) are required in order to access the protected information. This usually arises when some sensitive piece of information (such as an important corporate key that would, for example, unlock the central secure computer) is divided into several parts, each part being deposited with a different person for secure keeping. If, for example, it were split amongst 8 people, then it could be arranged so that the bringing together of any 6 of them would suffice to access the protected information. Techniques for doing this securely have been known for many years, though they are not yet as widely deployed as they should be. Now it would be foolish for the wording of the Bill to get involved in detailed technicalities such as "session keys". Nevertheless, it needs to be worded in such a way as to encompass all the above possibilities in as general a manner as possible. I therefore offer the following wording for your consideration: 11.-(1) Subject to the exception listed in subsection (2), a person required by a section 10 notice to disclose a key to some specified protected information, or to protected information of some specified class may, in order to satisfy that requirement, and at his choice, either (a) where there exists only a single key matching the requirement, disclose that key; or (b) where there exist several keys, any one of them being sufficient to match the requirement, disclose any such key; or (c) where there exist several keys needing to be assembled together in order to match the requirement, disclose such of them as are in his possession; or (d) where there exist several keys needing to be assembled together in order to match the requirement, make arrangements with other persons who have also been given section 10 notices, and are in possession of such of those keys as he does not himself possess, to derive from them a single key which matches the requirement, and then disclose that key; or (e) where the notice specifies a class of protected information likely to come into the possession of any person persuant to subsection (1) paragraphs (a) or (b), make arrangements for keys to specific items of protected information to be disclosed in a rapid and timely manner upon being presented with those items, or at least with sufficient parts of them, by the officer who gave the notice; or (f) where he is in a position to disclose any key or keys in accordance with paragraphs (a) to (e) above, and the protected information is already in an intelligible form but cannot readily be accessed without that key or keys, use that key or keys to access the protected information and then disclose it in place of that key or keys, provided he does so by the time before which he would otherwise have been required to provide that key or keys; or (g) where he is in a position to disclose any key or keys in accordance with paragraphs (a) to (e) above, and the protected information cannot readily be put into an intelligible form without that key or keys, use that key or keys to put the protected information into an intelligible form and disclose that intelligible form in place of that key or keys, provided he does so by the time before which he would otherwise have been required to provide that key or keys, and provided he is able to demonstrate that the form disclosed corresponds to the protected information provided. Observe that I have distinguished (f) (access to unencrypted information protected by some lock, and which I have already suggested should be excluded from the bill anyway) from (g) (decryption, or putting into intelligible form). Now to the matter of the right of the LEA to demand keys even when decrypted information is on offer. I oppose this also, but here is the wording that would apply if it is needed. Note that I have carefully excluded case (f) above - if the data itself is offered, why on earth should the LEA require the key (in this case the password) as well? 11.-(2) A person required to disclose a key to protected information may not avail himself of the option instead to put it into intelligible form as provided in paragraph (g) of subsection (1) if (a) the relevant authority who for the pourposes of Schedule 1 granted the permission for the giving of a section 10 notice in relation to that information, or (b) a person whose permission for the giving of such a notice in relation to that information would constitute the appropriate permission under that Schedule, has given a direction that the requirement can be complied with only by the disclosure of the key itself. Such a direction shall not be given unless there are exceptional and cogent reasons whereby disclosure of the protected information in intelligible form would vitiate the whole purpose of serving the notice. That last sentence (which could perhaps be worded better) is intended to make it clear that such directions are not to be given by those with the relevant authority (that is the Secretary of State, Judges, etc) as a matter of routine, but only reserved for exceptional situations (which the Tribunal might want to be explained to them afterwards). I find it hard to imagine a circumstance where this would apply, expect perhaps where the person on whom the notice was served was himself under suspicion, and the LEAs has come into possession of encrypted communications which, for some reason, had not been delivered to that person, and which they did not want that person to see. It all sounds pretty far fetched to me. Parliament would certainly need to be convinced of the necessity for this if this feature is to remain in the bill. Section 12. +++++++++++ This and the following section contain so many violations of basic humans rights, notably the presumption of innocence until proved guilty, and is in such blatant disregard of the European Convention on Human Rights (shortly to be enacted into British Law) that the mind boggles. How Ministers could stand up in public and deny these breaches beggars belief. However, these matters have already raised such a furore that I have no doubt that other commentators will have addressed them fully. -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQB8AwUBN/4Z2K1e6k0sFfGpAQGdAQMyApV2VR+UrBduXvWIUYetc7k0PXEjR0ac R77i6SedxMORSslh4JaXYoNDFpZ7a2zmDbHvkzNkxjCkJASkgEbjOgFBL9dWk5xI mcpBEaGa/HOoYHitUR4YHETZM0gbibiToopguaKALw== =dPWj -----END PGP SIGNATURE-----
The Foundation for Information Policy Research is registered in England and Wales under the Companies Act 1985 as a private company limited by guarantee (No.3574631). Application for charitable status is in progress.
Last Revised: October 17 1999