---

Identity Cards Bill

moved Amendment No. 32A:"Page 42, line 38, leave out ““a”” and insert ““an encrypted””" The noble Earl said: My Lords, this is all a bit technical, but what I am trying to do is to assist the Government, quite genuinely, and to make sure that they do not paint themselves into a corner with regard to future security things in the pipeline. Basically, paragraph 8 of Schedule 1, concerning security information, lists the sort of things you might want for a rather conventional current banking system. You would recognise the first two—the sort of things one might have in a chip and PIN system, as rolled out through supermarkets. Then in sub-paragraph (c) are questions and answers, or challenge and response as it is sometimes referred to, for trying to find out if a person is a person when they have forgotten their PIN. That all looks absolutely fine, but the way they have worded it makes it look as if they want to keep the personal identification number clearly. That is quite common in some cases, but a lot of more secure systems are moving to keep that in an encrypted or hashed form, where one can use it to verify the number that is coming down the line but the person looking at the database cannot actually read the number. That therefore secures against data leakage. Equally so, if you are doing that, you do not want just to generate some code from the personal identification number, but to have something there where you might need to verify a hashed number coming in from the terminal. I made a mistake in my amendment, so we would need to come back—the Government might want put something in on Third Reading or they may wish to ignore it for reasons I will mention in half a second—and probably ought to put in ““generating or verifying””, so that you cover both the currently envisaged system with fairly low cryptographic security but also encompass some newer ones coming along where you might want higher security. The trouble with this is that you have painted yourself into a corner. I was very pleased to hear the noble Lord, Lord Bassam, say in his response to Amendment No. 4—talking about the Data Protection Act 1998—that you want to keep everything in a very secure manner. Therefore, I imagine you would want to move forwards. The thing is that in the more modern systems, you may well want to move to what they call strong asymmetric mutual authentication, where you generate a password one end and it is decrypted at the other end with a different password. This is all to do with public key encryption and sometimes digital signatures—they are a particular case of it. There is a lot of work going on in this area. You do not necessarily need to go so strongly into this area if you are using the current supermarket and credit card chip and PIN, where you have terminal in a known place, with a known serial or security number, and things like that, all nailed down. Then you can get away with this weaker stuff. The problem comes with what the noble Baroness said earlier about people being able to change their addresses easily online. If you are going to make it easy for people to go online from their computers or some other terminal and key in their ID number and their PIN to identify themselves, or perhaps through questions and answers—a bit like some of the banks do at the moment—and that is all held and clear at the other end, the trouble is that it is not very secure. That is prone to phishing and hacking attacks and, nowadays that it is done from personal computers, to Trojans that can sit there. You will probably not permit it at the moment, with the sort of technology we are talking about here. If you want to move to more advanced technology—the sort of stuff that is coming out over the next two to three years—you are also going to have to keep encrypted data in the database. There are some international standards probably going to emerge in this area, to be widely available and of which the Government I am sure will want to avail themselves. You may want to encrypt anyway, to keep it more secure. I suggest that you go back and look at this, because you do not want to block out the chance of going to the newer stuff. I was told that it will not matter because, under Clause 3(1)(b), you will be allowed to put in technical information. All this security information currently comes under Clause 3(1)(a), which states,"““information the inclusion of which in an individual’s entry is authorised by Schedule 1””." Security information is classified under Clause 3(1)(a) and not under Clause 3(1)(b). One might say that if the technical stuff changes, we could put it under Clause 3(1)(b) and change what one holds against someone’s entry. However, assuming my understanding of how the legal mind works is correct, if one has explicitly stated that security information is covered under Clause 3(1)(a), it cannot be included under Clause 3(1)(b). That paragraph must refer to other sorts of technical information. Its inclusion under Clause 3(1)(a) will not be permitted. If someone with the old technology decided to make mischief, he might take a case to court and say, ““Actually, under the Act, you weren’t allowed to move to better stuff, because you weren’t permitted to keep the stuff on the register which would allow you to move to more secure cryptographic techniques. It must be excluded or it would have been in there in the first place because of Clause 3(1)(a)””. I know that that sounds like a terrible muddle, but if one reads the amendment, it should work out. Paragraph 8 of Schedule 1 should be more inclusive. It should not be limited to unencrypted data. I beg to move.