- Email: [email protected]
Security considerations for encryption products
Vol. 10, No. 11, Page 9
virus within the next five years. vendor and see what happens.
Try that on a
Of course, steps must be taken to reduce the threat of a computer virus infection. Verifying the boot sector, the operating system, COMMAND.COM and CONFIG.SYS is a minimum. Checking floppy disks for date and size of COMMAND.COM and possible bad sectors is protection against the known versions of the Lehigh and Brain viruses. How about the others? Using cryptographic checksums of executable programs and verifying them before the program is executed is another protective measure.
Note 1 In the 31 January 1988 issue of The New York Times, the article about computer viruses contained the following: “Buried within the code of the virus discovered at the University of Delaware was an apparent ransom demand: Computer users who discovered the virus were told to send $2000 to an address in Pakistan to obtain an immunity program, according to Harold Highland . .. .. . The Pakistani contact was not identified.” This statement was never made and the author of the article admits that it was never made. Somewhere in the editing, the copy was altered. I stated that the names of the two authors and their address in Lehore, Pakistan were included and there was even a copyright notice as part of the virus. Dr Harold Joseph Highland FIGS
SECURITY CONSIDERATIONS ENCRYPTION PRODUCTS
FOR
Abstract
which users can assess the packages; and describes to set up a complete security a secure encryption package.
(Readers may recall that the April 1987 issue of CFSB reported how Martin Kochanski, the author of this paper, broke the algorithm of the Fortress package. His company, Business Simulations L td, supplies PC da taban k, security and acceleration software.)
How our code-breaking
began
Among our other activities, we supply data security products. The first is FAP4; this is a hardware fast arithmetic processor, the world’s first commercially available chip for public-key encryption using the RSA and similar methods. The second is Ultralock, a transparent fine-grain file encryption program for the IBM PC and similar computers. It uses a unique proprietary algorithm to combine security with the speed necessary for a transparent system. As the manufacturers of Ultralock, we naturally keep an eye on the market, and assess security products as they appear, on criteria such as key management, ease of use, efficiency, and so on. We always assumed that there was no need to investigate the encryption algorithms themselves, because no manufacturer would be foolish or unethical enough to sell a product that was fundamentally flawed. We happen to own a copy of Superkey from Borland International. This is a keyboard enhancer with a file encryption feature. “An encrypted file contains absolutely no information about the encryption _._ Borland International cannot help you restore scrambled files. ” One afternoon, in a moment of boredom, I decided to have a look at the algorithm it used. I created a file consisting entirely of binary zeros, and encrypted
This paper describes some of the weaknesses that have been found in commercially available encryption packages;
COMPUTER FRAUD & SECURITY BULLETIN
suggests ways in security of various the steps needed system based on
it.
Here is the result (The lengths of the lines in this binary display have been chosen to shown the pattern at its clearest):
o 1998 Elsevier Science Publishers Ltd., England. /88/$0.00+ 2.20 No part of this publication may be reproduced. stored in a retrieval system. or transmitted by any form or by any means, electronic. mechanical, photocopying. recording or otherwise, without the prior permission of the publishers (Readers in the U.S.A. - please see special regulations listed on back cover.]
Vol. 10, No.11, Page 10
00011000
00101101 10010110
10100010
00101001
01010001
10100111
10100100
10101000
11010011
01011010 00100101
00011000 00001100
11101001
00000110
11110100
00000011
01111010
10000001 11000000
00001100
01001011 10100101
01010100 00101010 00010101
10010010 01001001 10100100
01010010
00111101 10011110 01001111
10100111 11010011
01100000 00110000 00011000
00001100 00000110 00000011
Any secure encryption algorithm will make even the most uniform data look random. Superkey produced a very non-random result, so it was obviously very insecure. About half an hour’s work sufficed to deduce the algorithm. It took another half an hour to write a program to decrypt an ASCII file without knowing the key. This work was done entirely out of idle curiosity. It required no arcane cryptographic knowledge, and so could be duplicated by any idle hacker with a spare afternoon.
The results Once we realized that manufacturers of security products might be using weak algorithms, we looked at a few more packages, always using the criterion of what a bored hacker might do in a spare afternoon. We looked at PS3, Padlock, N-Code, and Crypt: these were selected as simply being packages that came to our notice. Every one of them was breakable, mostly trivially. The package that was “generally accepted by cryptologists as being unbreakab/e”used a
COMPUTER FRAUD & SECURITY BULLETIN
pseudo-random generator. Although encryption algorithms that produce non-random output are insecure, it does not follow that random-looking algorithms are secure. This one was weak; it required only 6 bytes of guessed plaintext (anywhere in the file) to break it. Most English text, for instance, will contain the letters ‘ation’ or ‘there’ followed by a space, so there is a wide choice of 6-byte sequences to choose from. The package that used “a variant of the United States Government’s Data Encryption Standard”exclusive-ORed the data stream with an ordinary arithmetic progression and so required no known plaintext at all for decryption. It also stored all the keys in a directory protected with the same encryption algorithm. Far from requiring “vast amounts of time and equipment costing hundreds of thousands of pounds”, the program for breaking this package was 1 kilobyte long and took 30 seconds to run. Of the remaining two packages, one tended to destroy files without provocation; the other specifically claimed to be proof against
o 1988 Elsevier Science Publishers 1.td., England. /LW$O.OO + 2.20 No part of this publication may be reproduced, stored in a retrieval system. or transmitted by any term or by any means, electronic, mechanical, photocopying, recording or otherwise. without the prior permission of the publishers. (Readers in the U.S.A. -please see special regulations listed on back cover.)
Vol. 10, No. 11, Page
known-plaintext one.
attacks -but
succumbed
to
We published these results in the January 1987 issue of Cryptologia, and a simplified summary appeared
in PC Userin the same
month, accompanied suppliers.
by reactions from the
their suppliers so unconcerned, poor user to choose?
was so easy to break. If this ever happened to us, we would take steps to verify the claim; withdraw our product from the market and warn all our users; and redesign the algorithm. Of the three suppliers reviewed in the PC User article: -
One said that what we had done was a breach of licence agreement.
-
One claimed that a recent new release of the software had cured the weakness. We looked at the new release: the algorithm was unchanged.
-
One issued a new release of the software, making no mention of security or encryption algorithms. The algorithm had indeed been revised, and extra complications added, but it remained breakable if used in any normal commercial context.
We subsequently looked at Fortress, marketed by Deloitte Haskins and Sells, because it had the authority of a reputable international firm of accountants behind it. The Fortress algorithm was the weakest we had seen: it succumbed easily and trivially to a known-plaintext attack, and obligingly provided the known plaintext too (the details will appear in Cryptologia shortly). Deloittes responded to our report with a blustering attack which was couched entirely in marketing terms and avoided any mention of the real issues of security (see the April and May 1987 issues of CFSB) If so many packages are so weak, and
o 1988 Elsevier
Science
Publishers
how is the
Validation services It has been suggested that a security evaluation service is the answer. Indeed, we have been approached
One would expect any supplier of security software to be greatly alarmed by the news that the algorithm at the heart of the system
COMPUTER FRAUD & SECURITY BULLETIN
11
with offers to buy us
out of Ultralock (to avoid conflicts of interest) and set up such a service for a well-known magazine. There is no such thing as a security validation service, nor can there ever be: it is a mathematical impossibility. One can have an invalidation service, reporting on obviously weak and breakable packages, but this is not the same thing at all. If a package is broken quickly and easily, it is weak; but if it has not been broken in (say) two or three hours, this could be because the right approach happens not to have been tried. In an academic environment, the difference between ‘not [yet] invalidated’ and ‘validated’ is clearly understood; but in the commercial world, it would be a poor marketing man indeed that could not turn the former into the latter in just a few sentences, A further problem is the understandable caution of academics. The very weakest algorithms can be demonstrably broken. Very slightly less weak ones are obviously breakable to a trained eye. As algorithms get stronger, the presumption of security grows stronger, but everyone knowns that if he says “this is secure”, he may be proved wrong, while if he says “this is insecure”, he will never be. Add to this the large amounts of money at stake in the development of software packages, and you have a recipe for total chaos.
Some criteria The difficulty faced by a user seeking to evaluate the claim of rival encryption packages is that none of the usual obvious criteria work. If a word processing package corrupts the text it is printing, or a database package gives
Ltd., England.
/llfl/$O.OO + 2.20
No part of this publication may be reproduced, stored in a retrieval system. or transmitted by any form or by any means, electronic, mechanical, photocopying, recording or otherwise. without the prior permission of the publishers. (Readers in the U.S.A. - please see special regulations listed on back cover.)
Vol.10,
No.11,
Page
If the answer to any of the above questions is ‘Yes’, be suspicious.
Jones’s record when asked for Robinson’s, it does not take much expertise to see that there is something wrong. But the output of an insecure encryption package looks to a layman just like the output of a secure one.
-
Here is a checklist: General -
Who is the supplier?
-
What is his reputation
-
Who is the authorof the package, and of the encryption algorithm in particular?
-
What is his reputation? Is he active in cryptology? Does he publish papers, etc? One author’s reputation rested entirely on a career spent in setting brain-teasers in Sunday newspapers.
12
Can you specify a key, or is it built into the system, or even generated once and for all when the system is installed? If you cannot specify a key, then the risk of penetration will grow the longer the system is used.
Operation and standing?
-
Is the key displayed
as you enter it?
-
Is the key displayed while the encryption or decryption is proceeding? One package displayed the key prominently during each such operation -which took several minutes. We did not review this package further.
-
Is the system easy and fast to use? not, people will soon stop using it.
If it is
Algorithm -
-
Is it secure? You will probably only be able to assess this in terms of the author’s credentials. How fast is it? A very fast algorithm is probably insecure; a very slow one will be impractical to use, so no-one will use it.
Key management -
Can the system detect the use of incorrect keys?
-
Are keys stored on the disk or in files?
-
Can keys be recovered if they are forgotten? (One package supplied a ‘master disk’ that could rescue files if the user of the ‘slave’ disk had forgotten them. A onebit change to the ‘slave’ disk was enough to convert it into a ‘master’.)
-
Can files be rescued if the keys are forgotten?
Desirable features Transparency A conventional security system encrypts and decrypts files on request. The user must initiate each such operation and type the key. Unless the system has been weakened to be able to detect invalid keys, there is a danger that a mistyped key will result in permanent loss of data. The encryption process is slow, and the whole of a file needs to be processed even if only a small part of it is to be accessed: looking at one record in a 4-Mbyte database still requires the decryption and subsequent re-encryption of 4-Mbytes of data, even though only a few kilobytes may actually be referred to. Finally a conventional system cannot cope with the temporary files that many databases and word processors create and then delete: these files remain as plain text on the disk, and can be read by a number of standard utility programs. A transparent security system has no
COMPUTER FRAUD & SECURITY BULLETIN
Q 1988 Elsevier Science Publishers Ltd., England. /ll8/$0.00 + 2.20 No part of this publication may be reproduced, stored in a retrieval system, or transmitted by any form or by any means. electronic, mechanical, photocopying, recording or otherwise, without the prior permission of the publishers (Readers in the U.S.A. - please see special regulations listed on back cover.)
Vol. 10, No. 11, Page
provision for user-initiated encryption or decryption. Instead, it loads itself into memory and intercepts all program requests for reading and writing to protected files. After the operating system has read from the disk, but before the application program sees the result, the security system decrypts the data. After the application program has written some data, the security system encrypts them before they hit the disk. Thus all application programs behave just as they do when no security system is present. All protected files are kept permanently encrypted on the disk, so no additional user action is needed to provide security. Data is decrypted and encrypted only on demand, so only the required parts of a 4-Mbyte database would need to be processed - not the whole thing. If the wrong key is entered into a transparent system, there is little risk of harm. The first program to read a protected file will read nonsense, but only the data in memory will be affected: the disk copy will be untouched, so the correct key can be re-specified and all will be well. Finally, temporary files can be protected, so that writing and then deleting them will leave only encrypted data on the disk. Transparent security systems are gradually becoming more common (Ultralock was the first), but they are hard to write, and hard to write well. One of the packages we originally reviewed was intended to be transparent, but tended to activate itself when it was not needed, resulting in serious damage to data. Granularity It is rare for every file on a disk to need the same level of protection, especially when several different people are to be allowed access to the same machine. The term granularity is used to describe the level to which distinct keys can be specified. Disk granularity applies the same key to all the files
COMPUTER FRAUD & SECURITY BULLETIN
13
on a disk; directory granularity can apply different keys to different directories, or leave some of them unencrypted; file granularity can apply different keys to different classes of files even within a single directory. Non-transparent security systems have file granularity, because one can specify the files to be processed each time the program is invoked. With transparent security systems, it is desirable to have the finest grain possible preferably file granularity - to give maximum control over classes of authorization and encryption. Anything finer than disk granularity is very hard to achieve, but it can and has been done. Beware: some packages achieve directory granularity by remembering where each directory is on the disk. Run a disk optimizer package to reshuffle files on the disk for optimum performance, and you make all your files insecure, or unreadable, or both. Data interchange Some packages enforce isolation between systems by using partly or wholly built-in keys. This sounds like a good idea, and many reviewers have praised it, but it is actually a very bad thing: -
No genuinely secure system should need such a measure.
-
When data is being exchanged using floppy disks, isolation means that these disks must be unencrypted, at the very time when the data is most vulnerable.
-
If something goes wrong with a machine, all its data will be unreadable unless a pirate copy of the security software has been made.
Unobtrusiveness This feature is a matter of taste. Some packages wrap themselves up in elaborate trees of menus, with authorizations required at each level. If you want to use the system, you
0 1988 Elsevier Science Publishers Ltd., England. /88/$0.00 + 2.20 No part of this publication may be reproduced, stored in a retrieval system, or transmitted by any form or by any means, electronic. mechanical, photocopying, recording or otherwise, without the prior permission of the publishers. (Readers in the U.S.A. -please see special regulations listed on back cover.)
Vol. 10, No. 11, Page
have to put up with the menus, even if you already have your own favourite front-end or menu system such as Microsoft Windows. Other packages have no built-in user interface at ail. Keys are set by a simple DOS command, and the user can have any interface he likes.
Some claims to worry about Any hyperbolic security assertions - “Uses methods current in international espionage”, etc. -
-
“Each copy is unique”. This does not enhance security - if it is needed, then the system must have been weak to start with; and, as explained above, keys unique to each package can lead to data loss if anything goes wrong. “You can recover if you lose your keys”. This means that the keys are stored somewhere on the disk, and is an excellent point of attack for anyone trying to break the system.
-
“Each copy uses a different algorithm”. This statement (which we have heard from one security system supplier) is obviously untrue. Its interest lies in the fact that the speaker clearly cannot distinguish between an algorithm and a key; which casts doubt on the competence of the supplier’s organization as a whole.
-
“You can change keys in moments”. This means that they are not keys, but passwords, which is why re-encryption is required. In that case, are you able to change the key at all? It is bad practice to leave the same key in use for too long.
14
automatically for various classes of files. The only way of setting up a proper transparent system is to copy everything off your hard disk, set up the keys, and then copy everything onto it again. Any other approach is dangerous, because the disk may be left in a half-way stage, with some files encrypted and others unencrypted. Packages that offer short cuts to installation may seem to have advantages, but they can only achieve their extra speed by reducing the safety of the installation process. And, after all, you only install a security system once.
How to set up a secure system Initial audit -
Who uses which data, and for what?
-
How many different classes of use should there be?
Different people need to have access to different classes of data. Sometimes these requirements may overlap, as in the following example:
Ease of setting up versus ease of use Do not expect to get instant security. For example, a transparent encryption system handles decryption and encryption
COMPUTER FRAUD & SECURITY BULLETIN
User 1 has access to class A, user 2 has access to class B.
0 1988 Elsevier Science Publishers Ltd., England. /88/$0.00 + 2.20 No part of this publication may be reproduced, stored in a retrieval system. or transmitted by any torm or by any means. electronic, mechanical, photocopying, recording or otherwise, without the prior permission of the publishers (Readers in the U.S.A. -please see special regulations listed on back cover.]
Vol. 10,
In this case, the classes should be decomposed as follows:
No. 11, Page
15
file’ - that lists the files and directories to be protected, but does not actually specify the keys to be used. When someone wants to access a given use class, he enters the name of the key file and then the key to be used for this use class. There is no need to encrypt key files, because they contain no information about encryption keys. There is no need for a security manager: if people want new use classes, they can create them and set up the appropriate
key files to go with them.
If we assume a properly secure encryption
User 1 has access to classes A and C, user 2 has access to classes B and C.
Scheme complexity There are two possible key management schemes: single-level and two-level. In a single-level scheme, users are given the actual encryption keys for the use classes that they are allowed to access. In a two-level scheme, users are given personal keys, and these in turn control access to lists of actual encryption keys. -
How many staff are involved?
-
What sort of staff turnover
-
How often will keys be changed?
is there?
If there are few use classes, if very few people need to know keys and there is a low rate of staff turnover, and if the encryption keys themselves remain the same for long periods, a single-level key management scheme is sufficient. If any of these conditions is not met, the additional complexity of a two-level scheme is necessary.
Single-level
key management
system, there is no way to recover encrypted data if the original key has been lost. To protect against loss or forgetfulness, maintain a file (called MASTER.KEY, perhaps) that contains a list of all the encryption keys and the use classes to which they refer. MASTER.KEY itself can be kept on the system, but the key to MASTER.KEY is written down and kept locked in a safe. A secure encryption package will not be able to detect invalid keys. To get round this, create a dummy file which is encrypted with the same key as the class of files being accessed. Put a standard message in this file, and encrypt it along with the other members of its class. The batch file which sets keys should also run a program (unencrypted) that reads the dummy file and checks for the expected message. If the message is not correct, the key must have been wrongly specified.
Two-level key management For two-level management, manager is indispensable.
a security
Much of the architecture is the same as for single-level management. The security manager ensures encryption keys are assigned to use classes, as before. Next, he creates one key file for each user (not, as before, one file for each use class). Each user’s key file contains specifications of all the files in all the use classes he is allowed to
For each use class, create a file - the ‘key
COMPUTER FRAUD & SECURITY BULLETIN
o 1988 Elsevier Science Publishers Ltd., England. /tM/$O.OO + 2.20 No part of this publication may be reproduced, stored in a retrieval system. or transmitted by any form or by any means, electronic, mechanical, photocopying. recording or otherwise. without the prior permission of the publishers. (Readers in the U.S.A.-please see special regulations listed on back cover.]
Vol. 10, No. 11, Page
access, and contains the encryption each class.
key for
16
manager. If the manager has access to the users’ personal keys, this can be done without their intervention or knowledge; otherwise, a change of encryption keys can be arranged to coincide with a change of personal keys.
Each key file now contains secret information, so it must be encrypted. Each user chooses a personal encryption key, known only to himself, and encrypts his key file using it. In normal operation, there is no need for anyone to know the user’s personal key,
Conclusion The application of encryption is never as simple as it seems. Even when a secure system is found, the appropriate steps have to be taken to ensure that its application remains secure.
and no serious consequences follow if a user forgets his key. Nothing much happens if the user enters the wrong key either: the key file’s contents will then be unreadable and will be rejected.
Martin Kochanski Business Simulations London UK
Users must be forced to change their personal keys at regular intervals.
Ltd
Encryption keys for the use classes can be changed, slightly less often, by the security
Computer
Fraud
& Security
Subscription Price (inc. shipping & handling) E $ 1 year (12 issues) 265.00 135.00 635.00 325.00 3 years (36 issues) Subscription
enquiries,
Elsevrer Services (UK) Crown House Linton Road Barkmg Essex IGll8JU England Tel: 01-594-7272
Editorial
Dfl. 630.00 1510.00
orders and payments:
Elsevier Advanced Technology 52 Vanderbilt Avenue New York, NY 10017 USA Tel: (212) 370-5520
Publications
enquiries:
Elsevier Advanced Technology Mayfield House 256 Banbury Road Oxford OX2 7DH England Tel. (0865) 512242
Pubhcauons
No responsibility
is assumed by the Publisher for any injury and/or damage to persons or property as a matter of products liability, negligence or otherwise, or from any use or operation of any methods, products, instructions or ideas contained in the material herein. Special regulations
ADVANCED TECHNOLOGY
for readers III the U.S.A. This pubhcatron has been regrstered wrth the Copyright Clearance Center Inc. Consent 1s grven for copymg of artrcles for personal or mternal Gse, or for the personal use of specrfrc chents The consent 1s given on the condition that the coprer pays through the Center the per-copy fee stated m the code on’each page for copying beyond that pernutted by Sectlons 107 or 108 of the U S. Copyrlght Law. The appropriate fee should be forwarded with a copy of each page reproduced to the Copyright Clearance Center Inc.. 21 Congress Street, Salem MA 01970, U.S.A This consent does not extend to other kmds of copymg, such as for general drstrlbutron, resale, advertlsmg and promotlon purposes. or for creatmg new collective works. Special wrltten permissIon must be obtamed from the pubhsher for such copymg
Pr,nted,n Great Braan by ExpressLItho Serwce IOxford
virus within the next five years. vendor and see what happens.
Try that on a
Of course, steps must be taken to reduce the threat of a computer virus infection. Verifying the boot sector, the operating system, COMMAND.COM and CONFIG.SYS is a minimum. Checking floppy disks for date and size of COMMAND.COM and possible bad sectors is protection against the known versions of the Lehigh and Brain viruses. How about the others? Using cryptographic checksums of executable programs and verifying them before the program is executed is another protective measure.
Note 1 In the 31 January 1988 issue of The New York Times, the article about computer viruses contained the following: “Buried within the code of the virus discovered at the University of Delaware was an apparent ransom demand: Computer users who discovered the virus were told to send $2000 to an address in Pakistan to obtain an immunity program, according to Harold Highland . .. .. . The Pakistani contact was not identified.” This statement was never made and the author of the article admits that it was never made. Somewhere in the editing, the copy was altered. I stated that the names of the two authors and their address in Lehore, Pakistan were included and there was even a copyright notice as part of the virus. Dr Harold Joseph Highland FIGS
SECURITY CONSIDERATIONS ENCRYPTION PRODUCTS
FOR
Abstract
which users can assess the packages; and describes to set up a complete security a secure encryption package.
(Readers may recall that the April 1987 issue of CFSB reported how Martin Kochanski, the author of this paper, broke the algorithm of the Fortress package. His company, Business Simulations L td, supplies PC da taban k, security and acceleration software.)
How our code-breaking
began
Among our other activities, we supply data security products. The first is FAP4; this is a hardware fast arithmetic processor, the world’s first commercially available chip for public-key encryption using the RSA and similar methods. The second is Ultralock, a transparent fine-grain file encryption program for the IBM PC and similar computers. It uses a unique proprietary algorithm to combine security with the speed necessary for a transparent system. As the manufacturers of Ultralock, we naturally keep an eye on the market, and assess security products as they appear, on criteria such as key management, ease of use, efficiency, and so on. We always assumed that there was no need to investigate the encryption algorithms themselves, because no manufacturer would be foolish or unethical enough to sell a product that was fundamentally flawed. We happen to own a copy of Superkey from Borland International. This is a keyboard enhancer with a file encryption feature. “An encrypted file contains absolutely no information about the encryption _._ Borland International cannot help you restore scrambled files. ” One afternoon, in a moment of boredom, I decided to have a look at the algorithm it used. I created a file consisting entirely of binary zeros, and encrypted
This paper describes some of the weaknesses that have been found in commercially available encryption packages;
COMPUTER FRAUD & SECURITY BULLETIN
suggests ways in security of various the steps needed system based on
it.
Here is the result (The lengths of the lines in this binary display have been chosen to shown the pattern at its clearest):
o 1998 Elsevier Science Publishers Ltd., England. /88/$0.00+ 2.20 No part of this publication may be reproduced. stored in a retrieval system. or transmitted by any form or by any means, electronic. mechanical, photocopying. recording or otherwise, without the prior permission of the publishers (Readers in the U.S.A. - please see special regulations listed on back cover.]
Vol. 10, No.11, Page 10
00011000
00101101 10010110
10100010
00101001
01010001
10100111
10100100
10101000
11010011
01011010 00100101
00011000 00001100
11101001
00000110
11110100
00000011
01111010
10000001 11000000
00001100
01001011 10100101
01010100 00101010 00010101
10010010 01001001 10100100
01010010
00111101 10011110 01001111
10100111 11010011
01100000 00110000 00011000
00001100 00000110 00000011
Any secure encryption algorithm will make even the most uniform data look random. Superkey produced a very non-random result, so it was obviously very insecure. About half an hour’s work sufficed to deduce the algorithm. It took another half an hour to write a program to decrypt an ASCII file without knowing the key. This work was done entirely out of idle curiosity. It required no arcane cryptographic knowledge, and so could be duplicated by any idle hacker with a spare afternoon.
The results Once we realized that manufacturers of security products might be using weak algorithms, we looked at a few more packages, always using the criterion of what a bored hacker might do in a spare afternoon. We looked at PS3, Padlock, N-Code, and Crypt: these were selected as simply being packages that came to our notice. Every one of them was breakable, mostly trivially. The package that was “generally accepted by cryptologists as being unbreakab/e”used a
COMPUTER FRAUD & SECURITY BULLETIN
pseudo-random generator. Although encryption algorithms that produce non-random output are insecure, it does not follow that random-looking algorithms are secure. This one was weak; it required only 6 bytes of guessed plaintext (anywhere in the file) to break it. Most English text, for instance, will contain the letters ‘ation’ or ‘there’ followed by a space, so there is a wide choice of 6-byte sequences to choose from. The package that used “a variant of the United States Government’s Data Encryption Standard”exclusive-ORed the data stream with an ordinary arithmetic progression and so required no known plaintext at all for decryption. It also stored all the keys in a directory protected with the same encryption algorithm. Far from requiring “vast amounts of time and equipment costing hundreds of thousands of pounds”, the program for breaking this package was 1 kilobyte long and took 30 seconds to run. Of the remaining two packages, one tended to destroy files without provocation; the other specifically claimed to be proof against
o 1988 Elsevier Science Publishers 1.td., England. /LW$O.OO + 2.20 No part of this publication may be reproduced, stored in a retrieval system. or transmitted by any term or by any means, electronic, mechanical, photocopying, recording or otherwise. without the prior permission of the publishers. (Readers in the U.S.A. -please see special regulations listed on back cover.)
Vol. 10, No. 11, Page
known-plaintext one.
attacks -but
succumbed
to
We published these results in the January 1987 issue of Cryptologia, and a simplified summary appeared
in PC Userin the same
month, accompanied suppliers.
by reactions from the
their suppliers so unconcerned, poor user to choose?
was so easy to break. If this ever happened to us, we would take steps to verify the claim; withdraw our product from the market and warn all our users; and redesign the algorithm. Of the three suppliers reviewed in the PC User article: -
One said that what we had done was a breach of licence agreement.
-
One claimed that a recent new release of the software had cured the weakness. We looked at the new release: the algorithm was unchanged.
-
One issued a new release of the software, making no mention of security or encryption algorithms. The algorithm had indeed been revised, and extra complications added, but it remained breakable if used in any normal commercial context.
We subsequently looked at Fortress, marketed by Deloitte Haskins and Sells, because it had the authority of a reputable international firm of accountants behind it. The Fortress algorithm was the weakest we had seen: it succumbed easily and trivially to a known-plaintext attack, and obligingly provided the known plaintext too (the details will appear in Cryptologia shortly). Deloittes responded to our report with a blustering attack which was couched entirely in marketing terms and avoided any mention of the real issues of security (see the April and May 1987 issues of CFSB) If so many packages are so weak, and
o 1988 Elsevier
Science
Publishers
how is the
Validation services It has been suggested that a security evaluation service is the answer. Indeed, we have been approached
One would expect any supplier of security software to be greatly alarmed by the news that the algorithm at the heart of the system
COMPUTER FRAUD & SECURITY BULLETIN
11
with offers to buy us
out of Ultralock (to avoid conflicts of interest) and set up such a service for a well-known magazine. There is no such thing as a security validation service, nor can there ever be: it is a mathematical impossibility. One can have an invalidation service, reporting on obviously weak and breakable packages, but this is not the same thing at all. If a package is broken quickly and easily, it is weak; but if it has not been broken in (say) two or three hours, this could be because the right approach happens not to have been tried. In an academic environment, the difference between ‘not [yet] invalidated’ and ‘validated’ is clearly understood; but in the commercial world, it would be a poor marketing man indeed that could not turn the former into the latter in just a few sentences, A further problem is the understandable caution of academics. The very weakest algorithms can be demonstrably broken. Very slightly less weak ones are obviously breakable to a trained eye. As algorithms get stronger, the presumption of security grows stronger, but everyone knowns that if he says “this is secure”, he may be proved wrong, while if he says “this is insecure”, he will never be. Add to this the large amounts of money at stake in the development of software packages, and you have a recipe for total chaos.
Some criteria The difficulty faced by a user seeking to evaluate the claim of rival encryption packages is that none of the usual obvious criteria work. If a word processing package corrupts the text it is printing, or a database package gives
Ltd., England.
/llfl/$O.OO + 2.20
No part of this publication may be reproduced, stored in a retrieval system. or transmitted by any form or by any means, electronic, mechanical, photocopying, recording or otherwise. without the prior permission of the publishers. (Readers in the U.S.A. - please see special regulations listed on back cover.)
Vol.10,
No.11,
Page
If the answer to any of the above questions is ‘Yes’, be suspicious.
Jones’s record when asked for Robinson’s, it does not take much expertise to see that there is something wrong. But the output of an insecure encryption package looks to a layman just like the output of a secure one.
-
Here is a checklist: General -
Who is the supplier?
-
What is his reputation
-
Who is the authorof the package, and of the encryption algorithm in particular?
-
What is his reputation? Is he active in cryptology? Does he publish papers, etc? One author’s reputation rested entirely on a career spent in setting brain-teasers in Sunday newspapers.
12
Can you specify a key, or is it built into the system, or even generated once and for all when the system is installed? If you cannot specify a key, then the risk of penetration will grow the longer the system is used.
Operation and standing?
-
Is the key displayed
as you enter it?
-
Is the key displayed while the encryption or decryption is proceeding? One package displayed the key prominently during each such operation -which took several minutes. We did not review this package further.
-
Is the system easy and fast to use? not, people will soon stop using it.
If it is
Algorithm -
-
Is it secure? You will probably only be able to assess this in terms of the author’s credentials. How fast is it? A very fast algorithm is probably insecure; a very slow one will be impractical to use, so no-one will use it.
Key management -
Can the system detect the use of incorrect keys?
-
Are keys stored on the disk or in files?
-
Can keys be recovered if they are forgotten? (One package supplied a ‘master disk’ that could rescue files if the user of the ‘slave’ disk had forgotten them. A onebit change to the ‘slave’ disk was enough to convert it into a ‘master’.)
-
Can files be rescued if the keys are forgotten?
Desirable features Transparency A conventional security system encrypts and decrypts files on request. The user must initiate each such operation and type the key. Unless the system has been weakened to be able to detect invalid keys, there is a danger that a mistyped key will result in permanent loss of data. The encryption process is slow, and the whole of a file needs to be processed even if only a small part of it is to be accessed: looking at one record in a 4-Mbyte database still requires the decryption and subsequent re-encryption of 4-Mbytes of data, even though only a few kilobytes may actually be referred to. Finally a conventional system cannot cope with the temporary files that many databases and word processors create and then delete: these files remain as plain text on the disk, and can be read by a number of standard utility programs. A transparent security system has no
COMPUTER FRAUD & SECURITY BULLETIN
Q 1988 Elsevier Science Publishers Ltd., England. /ll8/$0.00 + 2.20 No part of this publication may be reproduced, stored in a retrieval system, or transmitted by any form or by any means. electronic, mechanical, photocopying, recording or otherwise, without the prior permission of the publishers (Readers in the U.S.A. - please see special regulations listed on back cover.)
Vol. 10, No. 11, Page
provision for user-initiated encryption or decryption. Instead, it loads itself into memory and intercepts all program requests for reading and writing to protected files. After the operating system has read from the disk, but before the application program sees the result, the security system decrypts the data. After the application program has written some data, the security system encrypts them before they hit the disk. Thus all application programs behave just as they do when no security system is present. All protected files are kept permanently encrypted on the disk, so no additional user action is needed to provide security. Data is decrypted and encrypted only on demand, so only the required parts of a 4-Mbyte database would need to be processed - not the whole thing. If the wrong key is entered into a transparent system, there is little risk of harm. The first program to read a protected file will read nonsense, but only the data in memory will be affected: the disk copy will be untouched, so the correct key can be re-specified and all will be well. Finally, temporary files can be protected, so that writing and then deleting them will leave only encrypted data on the disk. Transparent security systems are gradually becoming more common (Ultralock was the first), but they are hard to write, and hard to write well. One of the packages we originally reviewed was intended to be transparent, but tended to activate itself when it was not needed, resulting in serious damage to data. Granularity It is rare for every file on a disk to need the same level of protection, especially when several different people are to be allowed access to the same machine. The term granularity is used to describe the level to which distinct keys can be specified. Disk granularity applies the same key to all the files
COMPUTER FRAUD & SECURITY BULLETIN
13
on a disk; directory granularity can apply different keys to different directories, or leave some of them unencrypted; file granularity can apply different keys to different classes of files even within a single directory. Non-transparent security systems have file granularity, because one can specify the files to be processed each time the program is invoked. With transparent security systems, it is desirable to have the finest grain possible preferably file granularity - to give maximum control over classes of authorization and encryption. Anything finer than disk granularity is very hard to achieve, but it can and has been done. Beware: some packages achieve directory granularity by remembering where each directory is on the disk. Run a disk optimizer package to reshuffle files on the disk for optimum performance, and you make all your files insecure, or unreadable, or both. Data interchange Some packages enforce isolation between systems by using partly or wholly built-in keys. This sounds like a good idea, and many reviewers have praised it, but it is actually a very bad thing: -
No genuinely secure system should need such a measure.
-
When data is being exchanged using floppy disks, isolation means that these disks must be unencrypted, at the very time when the data is most vulnerable.
-
If something goes wrong with a machine, all its data will be unreadable unless a pirate copy of the security software has been made.
Unobtrusiveness This feature is a matter of taste. Some packages wrap themselves up in elaborate trees of menus, with authorizations required at each level. If you want to use the system, you
0 1988 Elsevier Science Publishers Ltd., England. /88/$0.00 + 2.20 No part of this publication may be reproduced, stored in a retrieval system, or transmitted by any form or by any means, electronic. mechanical, photocopying, recording or otherwise, without the prior permission of the publishers. (Readers in the U.S.A. -please see special regulations listed on back cover.)
Vol. 10, No. 11, Page
have to put up with the menus, even if you already have your own favourite front-end or menu system such as Microsoft Windows. Other packages have no built-in user interface at ail. Keys are set by a simple DOS command, and the user can have any interface he likes.
Some claims to worry about Any hyperbolic security assertions - “Uses methods current in international espionage”, etc. -
-
“Each copy is unique”. This does not enhance security - if it is needed, then the system must have been weak to start with; and, as explained above, keys unique to each package can lead to data loss if anything goes wrong. “You can recover if you lose your keys”. This means that the keys are stored somewhere on the disk, and is an excellent point of attack for anyone trying to break the system.
-
“Each copy uses a different algorithm”. This statement (which we have heard from one security system supplier) is obviously untrue. Its interest lies in the fact that the speaker clearly cannot distinguish between an algorithm and a key; which casts doubt on the competence of the supplier’s organization as a whole.
-
“You can change keys in moments”. This means that they are not keys, but passwords, which is why re-encryption is required. In that case, are you able to change the key at all? It is bad practice to leave the same key in use for too long.
14
automatically for various classes of files. The only way of setting up a proper transparent system is to copy everything off your hard disk, set up the keys, and then copy everything onto it again. Any other approach is dangerous, because the disk may be left in a half-way stage, with some files encrypted and others unencrypted. Packages that offer short cuts to installation may seem to have advantages, but they can only achieve their extra speed by reducing the safety of the installation process. And, after all, you only install a security system once.
How to set up a secure system Initial audit -
Who uses which data, and for what?
-
How many different classes of use should there be?
Different people need to have access to different classes of data. Sometimes these requirements may overlap, as in the following example:
Ease of setting up versus ease of use Do not expect to get instant security. For example, a transparent encryption system handles decryption and encryption
COMPUTER FRAUD & SECURITY BULLETIN
User 1 has access to class A, user 2 has access to class B.
0 1988 Elsevier Science Publishers Ltd., England. /88/$0.00 + 2.20 No part of this publication may be reproduced, stored in a retrieval system. or transmitted by any torm or by any means. electronic, mechanical, photocopying, recording or otherwise, without the prior permission of the publishers (Readers in the U.S.A. -please see special regulations listed on back cover.]
Vol. 10,
In this case, the classes should be decomposed as follows:
No. 11, Page
15
file’ - that lists the files and directories to be protected, but does not actually specify the keys to be used. When someone wants to access a given use class, he enters the name of the key file and then the key to be used for this use class. There is no need to encrypt key files, because they contain no information about encryption keys. There is no need for a security manager: if people want new use classes, they can create them and set up the appropriate
key files to go with them.
If we assume a properly secure encryption
User 1 has access to classes A and C, user 2 has access to classes B and C.
Scheme complexity There are two possible key management schemes: single-level and two-level. In a single-level scheme, users are given the actual encryption keys for the use classes that they are allowed to access. In a two-level scheme, users are given personal keys, and these in turn control access to lists of actual encryption keys. -
How many staff are involved?
-
What sort of staff turnover
-
How often will keys be changed?
is there?
If there are few use classes, if very few people need to know keys and there is a low rate of staff turnover, and if the encryption keys themselves remain the same for long periods, a single-level key management scheme is sufficient. If any of these conditions is not met, the additional complexity of a two-level scheme is necessary.
Single-level
key management
system, there is no way to recover encrypted data if the original key has been lost. To protect against loss or forgetfulness, maintain a file (called MASTER.KEY, perhaps) that contains a list of all the encryption keys and the use classes to which they refer. MASTER.KEY itself can be kept on the system, but the key to MASTER.KEY is written down and kept locked in a safe. A secure encryption package will not be able to detect invalid keys. To get round this, create a dummy file which is encrypted with the same key as the class of files being accessed. Put a standard message in this file, and encrypt it along with the other members of its class. The batch file which sets keys should also run a program (unencrypted) that reads the dummy file and checks for the expected message. If the message is not correct, the key must have been wrongly specified.
Two-level key management For two-level management, manager is indispensable.
a security
Much of the architecture is the same as for single-level management. The security manager ensures encryption keys are assigned to use classes, as before. Next, he creates one key file for each user (not, as before, one file for each use class). Each user’s key file contains specifications of all the files in all the use classes he is allowed to
For each use class, create a file - the ‘key
COMPUTER FRAUD & SECURITY BULLETIN
o 1988 Elsevier Science Publishers Ltd., England. /tM/$O.OO + 2.20 No part of this publication may be reproduced, stored in a retrieval system. or transmitted by any form or by any means, electronic, mechanical, photocopying. recording or otherwise. without the prior permission of the publishers. (Readers in the U.S.A.-please see special regulations listed on back cover.]
Vol. 10, No. 11, Page
access, and contains the encryption each class.
key for
16
manager. If the manager has access to the users’ personal keys, this can be done without their intervention or knowledge; otherwise, a change of encryption keys can be arranged to coincide with a change of personal keys.
Each key file now contains secret information, so it must be encrypted. Each user chooses a personal encryption key, known only to himself, and encrypts his key file using it. In normal operation, there is no need for anyone to know the user’s personal key,
Conclusion The application of encryption is never as simple as it seems. Even when a secure system is found, the appropriate steps have to be taken to ensure that its application remains secure.
and no serious consequences follow if a user forgets his key. Nothing much happens if the user enters the wrong key either: the key file’s contents will then be unreadable and will be rejected.
Martin Kochanski Business Simulations London UK
Users must be forced to change their personal keys at regular intervals.
Ltd
Encryption keys for the use classes can be changed, slightly less often, by the security
Computer
Fraud
& Security
Subscription Price (inc. shipping & handling) E $ 1 year (12 issues) 265.00 135.00 635.00 325.00 3 years (36 issues) Subscription
enquiries,
Elsevrer Services (UK) Crown House Linton Road Barkmg Essex IGll8JU England Tel: 01-594-7272
Editorial
Dfl. 630.00 1510.00
orders and payments:
Elsevier Advanced Technology 52 Vanderbilt Avenue New York, NY 10017 USA Tel: (212) 370-5520
Publications
enquiries:
Elsevier Advanced Technology Mayfield House 256 Banbury Road Oxford OX2 7DH England Tel. (0865) 512242
Pubhcauons
No responsibility
is assumed by the Publisher for any injury and/or damage to persons or property as a matter of products liability, negligence or otherwise, or from any use or operation of any methods, products, instructions or ideas contained in the material herein. Special regulations
ADVANCED TECHNOLOGY
for readers III the U.S.A. This pubhcatron has been regrstered wrth the Copyright Clearance Center Inc. Consent 1s grven for copymg of artrcles for personal or mternal Gse, or for the personal use of specrfrc chents The consent 1s given on the condition that the coprer pays through the Center the per-copy fee stated m the code on’each page for copying beyond that pernutted by Sectlons 107 or 108 of the U S. Copyrlght Law. The appropriate fee should be forwarded with a copy of each page reproduced to the Copyright Clearance Center Inc.. 21 Congress Street, Salem MA 01970, U.S.A This consent does not extend to other kmds of copymg, such as for general drstrlbutron, resale, advertlsmg and promotlon purposes. or for creatmg new collective works. Special wrltten permissIon must be obtamed from the pubhsher for such copymg
Pr,nted,n Great Braan by ExpressLItho Serwce IOxford