Harold Thimbleby
Journal of Systems and Software, 25(2), pp207-215
1994
Harold Thimbleby is Professor of Computing Research at Middlesex University, London, England. He obtained his PhD from Queen Mary College (now Queen Mary & Westfield College), London University in 1981. He is author of User Interface Design (ACM Press/Addison-Wesley, 1990) and, with George Coulouris, of HyperProgramming (Addison-Wesley, 1993) as well as of over 200 other publications. His research covers the design and programming of usable systems: avoiding computer viruses is, of course, one way to make computers easier to use.
He may be contacted by email at harold@mdx.ac.uk,or see his Web pages.
Conventional protection methods against software piracy and computer viruses are limited in their effectiveness and timeliness. A cryptographic method, introduced in this paper, can stop the spread of viruses of all kinds, stop software piracy, and can be ideal for organisational purposes. Computer use within an organisation is completely unaffected.
PERSONAL COMPUTERS are beset with twin problems. Computer piracy is commonplace and can result in legal action with heavy fines. Computer viruses, too, are commonplace, and they damage computer data, often including backups, and can make an organisation's computers inoperable. When organisational users have their own home computers or portable computers, the temptations for software piracy increases (maybe a teenage son 'borrows' his father's PC (Note 1) to run a friends' games) and the possible routes for virus infection increases. A trip to central Europe might easily bring back viruses that a US organisation's anti-virus software has not yet been updated to detect - or vice versa. The consequences can be disastrous.
This paper explains clearly how this problem may be avoided, subject only to (i) manufacturers (or, possibly internal programmers) providing the appropriate facilities; (ii) users agreeing that the marginal costs are worthwhile; (iii) users accepting the restrictions that not being able to pirate software implies. This paper is not intended as a treatise in cryptography or proprietary nostrums, since the proposed solution does not need to be dressed up as a pretentious or costly idea.
The usual solutions to virus and piracy problems are based in organisational procedure, supplemented with up-to-date antivirus software. These measures require individuals to adhere to the organisation policy (even when it is not fully adequate), to be sufficiently knowledgeable about the software, and they require a subscription to the antivirus software to ensure it remains capable against new virus developments. Moreover, there is a minor industry in supplying consultancy, software and hardware devices providing various degrees of protection.
Against this, people want to share information without 'artificial' restrictions. They see that with a personal computer they now have the means to do so: by exchanging floppy discs, by email, and by exchanging portable hard discs. The tension between security and communication is frustrating.
The tension can be removed as soon as it is realised that it is possible to distinguish between computers that one wants to communicate with and computers that one does not want to communicate with. Viruses may come from anyone who happens to be infected, but they originate with people that a user does not want to communicate with - certainly in hindsight, after getting a virus, they wish they hadn't! A solution, then, would be to distinguish and then isolate the people who do want to communicate from those who wish to disrupt them.
The people with whom you want to communicate are easy to identify, but the people with whom you don't want to communicate (directly or indirectly) are almost impossible to identify. It is necessary to distinguish at least these two classes of people, or, rather, to distinguish the programs and data that they construct and exchange.
However, the problem with present PCs is that they do not make any distinction, nor do they provide any basis on which a distinction may be based. There are historical reasons for this, arising from the general purpose nature of floppy discs. The floppy disc is not only used as the main way of booting computers (though for efficiency a hard disc or network may be used subsequently), it is also used for installing software, used for storing data (e.g., for backup or simply for extended capacity), and for exchanging programs and data between users. It has a many-fold role. The generality of PC operating systems means that no particular distinction is made between the roles:
Originally, a PC only had floppy discs, so all its 'permanent' (long term) information was removable. Users therefore owned discs, not machines. Today, PCs contain large, permanent hard discs, containing personal information belonging to at least one user. The historical design of PCs means that anyone can still boot them off a floppy disc, and effectively own all the information in them, whether accidentally or maliciously. A user 'borrowing' another's computer can infect the permanent information with a virus. The computing community is currently debating the transition from viewing computers as 'free for all' to personal and private resources. Various hardware devices, from lockable floppy disc drives to password schemes, have made unauthorised booting of PCs much harder.
Current defences to viruses may be classified as: gatekeepers, which try to intercept unauthorised actions (such as formatting a disc); checkers, which try to recognise signatures of known viruses; and checksum methods, which try to detect unauthorised changes of any kind. Defences may be provided as software packages or as hardware devices that are permanently installed in the PC. Passive methods include physically locking a PC, or otherwise limiting access to it or parts of its discs.
Gatekeepers and checkers both assume that unwanted actions can be recognised, and hence stopped. Unfortunately, there are infinitely many ways of doing unwanted things, so such methods must be regularly maintained (typically by subscription services) and kept up to date with all new virus signatures. To be reliable they must be kept ahead of virus developments, an increasingly difficult task as new viruses are released with alarming frequency.
Checksum methods have a number of problems: they are useless for checking newly acquired discs (as when installing new software). There is no 'correct' checksum that the new disc can be compared with to see if it has been tampered with. Further, many stealth viruses deceive checksum methods, so checksums are unreliable when used alone without any supplementary method. (Some better programs are now constructed with internal checksums so that they are able to detect modifications to their own code.)
Although use of unauthorised (e.g., unlicensed) commercial software may be detected using similar methods, none of the virus defence schemes have any impact on piracy (unauthorised copying of software), which remains one of the main sources of viruses.
The only reliable solution to both piracy and viruses would be to stop computers from communicating with the rest of the world, the source of both viruses and pirated software. This draconian measure is cheap, and can be most easily achieved by removing floppy disc drives from all PCs and limiting network capabilities. It provides no protection, if sophisticated users connect ports on their PC to bulletin boards or already infected computers.
Disconnecting computers, by removing floppy drives and communications ports other than essential networking removes many of the advantages of personal computing, in particular it renders portable computers useless. To the extent that a non-communication policy is successful, portable computers won't be able to talk to desktop computers.
The proposed solution is to install hardware encryption. Everything (electronic) that goes in and out of a PC is encrypted, using an organisation-specific code (or department-specific code: there are many schemes). All data on an organisation's floppies immediately becomes unreadable - because it is in code - for everyone outside the organisation. Conversely, all discs from outside are unusable on the organisation's own PCs because they have not been appropriately encoded. In effect, this scheme makes an organisation a closed community speaking its own language. It neither understands nor talks the languages of other organisations, and cannot share information (via PCs) with those other organisations. Thus it can neither receive viruses nor pirate software from outside. Likewise, it cannot contribute to piracy by copying software to outside organisations, nor can it spread viruses outside.
We obtain these advantages and impose no changes within the organisation. The way PCs within an organisation work, the way portable PCs talk to desktop PCs, and all other internal day-to-day matters are unchanged. There is no need for additional user awareness.
Because of the historical flexibility of PC computers, the method has to be based in or supplemented by (quite simple) hardware. Anything done in pure software could be subverted by rebooting a PC to work as normal. (We note that many companies provide hardware virus 'solutions' as well as various hardware devices for disc doubling: these, being of comparable complexity and cost, demonstrate the commercial and practical possibility of the concept.)
An example shows how the idea works.
A very simple code might substitute each letter by the next one along in the alphabet. When a user saves the word SECRET onto his disc, the disc actually records TFDSFU. (Or the 'program' WRITE(10) could be saved as XSJUF)21*.) Of course, a more sophisticated code would be used in practice, and would make things even less meaningful than in this example.
Anyone else's computer would see the encrypted information as nonsense, and so be unable to read the organisation's information, whether text, spreadsheets or programs. Other organisations' PCs would not be able to run programs stored on the coded disc. Everything is encoded and unintelligible to other PCs without the organisation's code. Each organisation uses a different code. (Note 2)
Conversely, a disc put in a computer is decoded. If the disc contains TFDSFU, it will be decoded to SECRET - as if nothing had happened. But if a disc from outside with a virus on it, say VIRUS, was decoded it would appear to have UHQTR on it. A virus, then, would appear to be nonsense, certainly not a functioning virus. Yet the disc with TFDSFU, the encoded organisation data, can be taken to any PC within the same organisation, slipped in and immediately appears as the original SECRET.
For people in the organisation, then, everything works exactly as before. If the user who saved SECRET onto his disc examines the file on his disc, it will seem to contain SECRET: just what he saved. Users don't need to know about the method, or adopt any new procedures. On the other hand, no viruses can be picked up, and no pirated software can be run, or given away.
This is a simple code example, yet we should dispel any worry that using a code is noticeable to users. Discs already save information in binary code. Of course, at present, every computer uses the same code, so nothing can be secret or safe. We're merely suggesting that each organisation uses a different, organisation-specific code. The code is rather like having a unique or idiosyncratic disc format; it makes discs from outside the organisation unreadable, and conversely, makes internal discs useless to people outside the organisation. The use of the code does not rely on programs on the PC doing anything special, and it applies equally to all programs and data - it applies to everything on a disc, even its boot and control blocks.
In reality, a more sophisticated code would be used than in this example. It could be made very secure. Even if many simple codes were used, the method would put an effective end to viruses because no virus could be designed that would spread successfully. The technology of computer codes is far more advanced than conventional lock and keys. However, lock and key technology is merely suggestive: master keys, with hierarchically-controlled access rights, are one of many possibilities. Computer codes can support: signatures (only authorised people can sign them); time stamps (the documents are authenticated as written at particular dates and times); anti-tamper devices (to reveal attempts to modify information); and self-modifying codes that change over time (to stop stolen computers being used to break the code).
It might be possible, after determined effort, to break into one organisation, but a successful intruder or virus attacking one organisation A would not be able to work in organisation B. And for 'organisation', you could read 'company', 'subsidiary', 'department' or even 'individual user'. The method can be applied with as fine a grain of security as desired. An entire organisation could use the same code, different codes could be used for different security regions, or the codes could be designed to enforce a particular security model.
Whether using hardware or software, since boot discs are encoded in the same way as all other data, users continue to operate their PCs in exactly the same way as before. This is an enormous advantage. All manuals and reference books, including all those for the operating system, retain their value; all training investment is upheld. The only difference is that a trusted person within the organisation must initially provide virus-checked discs using a machine that can read discs obtained with other codes and convert them to organisation-encoded discs.
The method makes PCs safe against booting from virus-infected or Trojan discs.
A specific benefit is that, as few organisational users require programming systems like compilers, if users have not been supplied with appropriately encoded programming systems then they would be unable to install any. Internal sabotage from hackers (when they had not been given the clearance to use programming systems) would not be possible. Secure communications software could not be tampered with.
The disadvantage of a hardware solution is its marginally higher cost. (Though its cost is far less than that of recovering from a severe virus infection or than the fines imposed for software piracy.)
However, software protection systems are appropriate for trusted users whose PCs are physically secure. But ordinary PCs can still be booted from 'any old' boot discs. Once booted with an unprotected system they can then be infected as easily as before. Even if a hardware-unprotected system is booted, any data on the PC's disc will still be encoded; to make this safe, the decoding software has to be able to check whether the operating system is authorised. In this example, it would not be and the decoding software should refuse to run. This would stop accidental infection of discs. Even so, any software system can be circumvented by fairly simple programming techniques if the user (or the virus he is unwittingly running!) is sufficiently motivated and knowledgeable.
Hardware solutions are fast and can be applied to all input/output ports on a PC. Doing so additionally renders networks (and telecoms) secure against the attachment of unauthorised computers. Encryption can compress data, and this would improve the effective data throughput and capacity of all devices. Conversely, since compression is a code, existing compression hardware could be used. To obtain the benefits described here, however, the hardware must compress data held on floppy discs and communications ports, as well as hard discs, but this is usually not difficult to arrange. What is surprising, then, is that compression methods have not been extended to cover all use of disc media without exception, and hence help protect against piracy and viruses. The existence and popularity of this hardware demonstrates that the technology is readily available and only needs minor adjustment.
Purely software solutions can only be an interim solution. If a proprietary software coding system became popular, somebody would sooner or later devise a virus that could reprogram it and circumvent its protection. A virus is unable to reprogram hardware. Standard hardware techniques, although they are not strictly uncompromisable, can be made arbitrarily difficult to compromise without specialist hardware - viruses spread on 'ordinary' PCs, not on ones that are everywhere equipped with special hacking hardware. If every PC user installs hardware to help them compromise the protection scheme, then we have a serious social problem, and one that technical 'solutions' would only escalate!
This article has stressed the organisational advantages of a cryptographic solution to viruses and piracy. But individual computer users also benefit.
One can imagine various schemes. When you go to a hardware store to buy a lock and key, you know that in principle somewhere someone else may have exactly the same key. But they are unlikely to live near you. Likewise, assigning random codes (seeds) to computers bought in high street shops would give them all different keys. Everyone would be secure enough against all computer viruses, and piracy would be eliminated. When a user buys software, he'd quote his key number to the software supplier, and then he'd get a disc that would only work on his computer. This puts some extra expense on software suppliers (and requires them to be trusted by the software manufacturers). However, note that some software is already supplied on this sort of basis: CD-roms can be bought containing far more software than is paid for at the time of purchase. Subsequent payments obtain keys from the supplier to unlock additional software on the CD-rom.
An important point is that this procedure can easily be automated (using public key encryption methods) so that, since a PC knows both its internal key and reputable manufacturers' public keys, it can decode with the public key and encode with its internal key: thus ensuring that only accredited software is installed and only from recognised suppliers. The user can, in this case, give the original software to a third party (piracy), but he cannot make unauthorised copies to distribute without the originals. Thus, this approach inhibits the professional pirate, but does not do much to stop small-time piracy. Although various schemes can be devised to handle the small-time pirate (such as limiting the number of installations), in practice these techniques have been very badly received by users and may discredit the manufacturer so much as to be counter-productive.
Though suppliers would have extra costs, they would be spared the embarrassment (and liability) of distributing viruses. There are many cases (such as when the European Patent Office distributed an infected disc to its customers in 1991) that show the risk is very real. If millions of pounds are being lost through piracy (to suppliers) and viruses (to users), some of the savings could readily be diverted to support the minor extra work required of suppliers.
The method proposed is a technical solution to virus infection and piracy. It does not address social problems of any sort. It does not address problems (such as fire, fraud and physical vandalism) that are other high risks for PC-based information. In particular if an organisation has determined internal hackers, or is the specific target of external hacking, the hackers may be able to subvert the protection.
The method does not encrypt the user's screen or keyboard. (The computer would be practically unusable if it did.) Thus, manually using the keyboard, or even by using OCR to copy the text of a virus program directly from a book, can get a viable virus into the PC irrespective of the encryption method. Users may do this, though it relies on the existence of, and the user's access to, a suitable programming environment, such as an assembler. (Unfortunately, many systems, such as spreadsheets, are user-extensible and are in themselves sufficiently powerful to implement viruses or other malicious code.)
Once 'inside' a virus can move within an organisation freely. For this form of subversion, fortunately, the method provides three advantages: first, the spread of the virus is limited to the organisation (thus, the organisation's risk of liability to third parties is limited); secondly, the size of the infectable part of the organisation can be limited by the method, and should therefore be commensurate with the hacker's seniority and security rating; thirdly, not all users need be authorised to have the appropriate programming tools to be able to program - the method also ensures that unauthorised users could not obtain such programs by piracy. In particular, there are shared key cryptographic techniques that ensure that no one user could install a virus: a suitable 'quorate' group of authorised users would then be required.
Because cryptographic methods can be used to limit the size of the department within the organisation that is infected, conversely the method makes it easier to identify the perpetrator. Inappropriate security clearances, incentives and disciplinary procedures for an organisation's personnel are separate, non-technical issues.
Given that organisations do want to communicate, and not always with completely trusted organisations or with completely trusted internal departments, the method may not be ideal for all purposes. However, it enables an organisation to choose a particular balance in the tradeoff between being open and unduly vulnerable, and being closed but secure. (Current PCs do not permit this!)
A solution to permit safe communication with untrusted organisations could be based on strong typing of messages throughout an organisation: thus, when electronic mail is received, it remains everywhere in the system as text and cannot be converted to program by any user, even with access to text editors and compilers. Of course, such a strategy changes the way systems are used, and we lose the backwards compatibility that the present paper's method offers. The suggestion of encrypting discs (and other media), however, is a necessary first step in a broader solution: without encryption, an intruder could simply get a disk (or network packet), copy it, change its type from text to program, and he would have got part way to creating a virus.
It would be possible in the long run for software suppliers to provide software that would only run on PCs with registered code numbers. Some software suppliers already do this on PCs by using dongles (these provide the secret codes) or on workstations, using processor numbers. Such methods would become cheap, automatic, reliable and universal. There would be no problem of user acceptability of dongles since the relevant hardware would be built in, and therefore not supplied with each piece of software to the user.
The alternative to a proper solution to computer viruses is that current designs of PCs will be obsoleted as the range and variety of computer viruses increases: ordinary PCs will become too risky to use. There will be too many new viruses that spread unknown and without hindrance before PCs are protected against them.
Automobile safety was initially an optional add on; now manufacturers recognise the cost-benefits of providing built-in safety, largely as a result of consumer pressure. At present, PC manufacturers make it appear that the responsibility and marginal cost for virus protection lies with the user. This article has shown that this need not be the case: effective solutions can be built into the hardware, and if done by manufacturers would have negligible cost. If protection is provided as a fixed part of the motherboard, hackers would not be able to subvert it by removing the hardware protection components and then (laboriously) decoding the disc with software.
Finally, perhaps we are being too optimistic? There is a lot of pressure to maintain the current situation.
For example, some computer operating systems automatically and transparently decode proprietary format discs from otherwise 'incompatible' manufacturers. This is doing exactly the opposite of what we need in order to be protected! But it is done because, with the current public perception of using computers, compatibility increases a manufacturer's market penetration. A manufacturer producing PCs with an idiosyncratic disc format would only have customers who did not want to talk to the wider world. On the other hand, they would be safe from external viruses and from cross-organisation piracy. The issue is that, at present, gaining safety in this way reduces the software base available to users. The solution suggested in this paper would enable users to gain the advantage of separation, but still be able to make use of the large software base available to all users of that type of PC (or workstation). Moreover, it would also mean that manufacturers would address the problem explicitly, enabling users to choose at what level they wish security. It need not be an either-or choice between being compatible and (sooner-or-later) infected, or incompatible and uninfected.
Several referees with (admitted) commercial interests in the topic of this paper claimed conceptual problems with its ideas. The following list summarises some of the relevant comments, and my responses to them.
(1) Certain proprietary software solutions address aspects of the problem; thus, what is the need for the solution discussed here? Response: These methods are restricted to the specific programs involved. They may limit piracy, typically relying on dongles or password schemes. They may enable virus infection to be more easily detected, with cryptographic checksums. But they don't affect or help any other programs. A general solution has advantages, particularly when it applies to the existing installed software base as well as newly acquired software.
(2) Encryption of DOS's COMMAND.COM file is unworkable, since MS-DOS needs it to be directly executable; thus, encryption can't work in general. Response: It would be decrypted like any other file obtained from disc (or network). The criticism shows that the method has not been understood; it does not depend on files (such as COMMAND.COM) decrypting themselves, though this is a method that can be used for some other types of executable file (with the problems addressed in point 1 above).
(3) Good industrial practice reduces the exchange of programs, and separates programs from data. Response: Not always. Besides, the PC hardware design does not require a distinction between programs and data, and in many cases (such as spreadsheets) the distinction is hard to maintain. This comment is a case of confusion about what happens frequently, and what can happen in practice.
(4) Universities are the greatest source of infection. Response 1: The statistics (and blame) of virus infection is interesting, but irrelevant. To remove virus and piracy problems, things have to be effectively impossible, not just unlikely. Moreover, our arguments don't depend on the detailed statistics. Response 2: The argument of this paper does not depend on what sector organisations are in; it does not distinguish between universities and other sorts of organisation. Since it works for universities, it will stop them being sources of infection or centres of piracy.
(5) Every virus infection is immediately reported. Response 1: Really? The problem here is that the viruses that aren't immediately reported are the ones that do more damage. Users without adequate antivirus support are unlikely to report viruses until after they have done serious damage. The medical adage: "prevention is better than cure" is true for computer viruses. Often, once a virus has been detected, it will have achieved some damage (either on the PC itself or on the incoming programs or data). Response 2: Which travels faster to the infected PC, the infection or its cure? (The comment seems to be based on the assumptions of a centralised antivirus business: knowing what new virus infections there are, and catching up with them. It is certainly not based on realistic protection for the first site to report the infection!)
(6) There is commercial software to inhibit 'warm reboots' from floppy drives (i.e., to stop software initiated rebooting from a floppy). Response: Such software certainly reduces the rate of accidental spread of a virus, but it does nothing for a deliberate attack by a hacker, who can bypass such software simply by doing a hardware reboot.
(7) The code suggested is naive. Response: Of course it is; it happens to be a Caesar cipher. It's purpose was to explain the approach, not to implement the approach.
(8) Some commercial packages also use simple codes, and these have been cracked by hackers; in some cases decryption software is widely available. Response 1: A simple code is not adequate, nor can the same code be used everywhere - at least the key has to be changed from site to site. Response 2: When commercial packages use the same code, then all users share the same encryption method, and as a community of similarly-encrypted users, they can all share viruses using that program as a vector. When the code is broken, it is broken everywhere. The idea of this paper is different: groups of users use different codes.
(9) Users do not want protected discs from manufacturers. Response 1: The system administrator alone gets the protected disc; once he has converted the program to the local code, it can be made available to all users as an ordinary disc, without appearing to be protected. (See also the comment above suggesting public key systems to avoid administrativehead.) Response 2: CD-roms are now used to supply encrypted programs as well as data such as fonts. A user typically telephones the CD-rom vendor, pays, and obtains a key to decrypt the software purchased. This shows that there is no problem providing encrypted software. Moreover, there is no technical reason why the vendor need not ask for the purchaser's organisation key; they would then supply not a decrypted piece of software, but software encrypted by the organisation's specific key (rather than the CD-rom's secret key).
(10) One software company already encrypts programs to hinder employee copying, though employees have to decrypt the programs before running them. The programs are then in plaintext and can be copied easily. Response: Neither the user nor the programs he runs ever perform an explicit decryption operation in the method proposed in this paper; there is never a decrypted version of the program (or data) available at the user-level that can be copied and given to anyone unauthorised. (Note 3) Of course, for the PC to work, the programs must get decrypted; but suppose a malicious user tries to make a pirate copy of a code of the program onto a disc - Êit simply gets re-encrypted as it is written to the disc, thus defeating the user's purpose.
(11) It requires the existence of a secure operating system for it to work. Response: The paper makes it clear that the method would work with MSDOS, which is not a secure operating system.
(12) If you have a secure system, you don't need this overkill solution. Response 1: Very few systems are secure. No secure system is compatible with MSDOS and all its existing applications! Response 2: The hardware required in the solution is no more sophisticated than already routinely used for disc compression. Moreover, the "overkill" is a cheap price to pay for an organisation that wants protection against viruses without retraining staff. One would not gain the advantages even if there was a "secure" operating system available.
(13) Hardware encryption boards are available, but a file encrypted on a Intel 80386 may not decrypt on a 80286. Response 1: This doesn't refute the point of this paper. Getting hardware to work properly is a serious engineering undertaking; in some cases it appears not to have been done professionally. Response 2: More optimistically, a company using even such a bad scheme as this one (so long as it applies automatically to everything on the discs, not just files) has isolated themselves from any virus originating on the other sort of machine. Response 3: one must distinguish between unreliable hardware and a concept that could be implemented reliably.
(14) Any scheme like this makes software development and testing harder. Response 1: The scheme proposed makes no difference to software development and testing within an organisation. So long as the scheme is implemented correctly, there is no way that a PC itself can detect the encrypted software as such or depend in any way on the particular encoded form of the software; the method itself can therefore have no impact on the reliability (or otherwise) of the software. Of course, it relies on the software supplier being able to encrypt data reliably; but one might well wonder that if this poses a serious problem, whether the supplier should stay in business! Response 2: Once new coding methods are used, it is sensible and trivial to include additional safeguards, such as checksums. These can be used to increase confidence that users are actually running the software as it left the suppliers, rather than some corrupted version. This should make software testing (in the field) easier.
(15) Virus protection was never designed to prevent piracy. Response: At one level this is an observation about existing methods, and does not reflect on this paper's proposals. At another level, it might be pointed out that existing virus protection and piracy prevention methods can use cryptographic methods. The proposal simply does both simultaneously.
(16) If you don't have a secure system, the 'solution' does not work, because it can be trivially subverted. Response 1: This is a puzzling comment since no method is proposed. There are trivial methods, certainly, but using physical sabotage. These methods attack PCs one at a time, and are therefore costly for a hacker to implement on any scale; they would not help propagate viruses, but they could help pirate software. Most physical methods can be avoided by integrating the encryption hardware within the microprocessor, so that any subversion (perhaps merely rewiring data paths) damages or disables the PC. Response 2: If the protection hardware can be removed, the hacker will merely be left with an encrypted disc, which is then useless. One may certainly obtain an ordinary PC by successfully disabling or removing the protection hardware, but it would be incompatible with the rest of the organisation's PCs.
Protecting against viruses is impractical and imperfect. New viruses are impossible to recognise. Instead of trying to recognise what is not wanted, instead recognise what is wanted. For organisations, what is wanted is unaffected internal communications, even when users are mobile.
A cryptographic technique, using codes specific to an organisation, is a simple and effective way of recognising what is wanted, and rejecting everything else. It can be done in such a way that use of a PC and its user is unaffected, yet the PC cannot be used to run outside programs, nor can it distribute programs or other information beyond the organisation. Restricting access to outside programs controls both piracy and viruses.
Few other virus protection methods could claim to be worthy of support from both users (particularly at the organisation level) and from software suppliers! The method not only stops virus infection entering an organisation, it also stops piracy, and hinders many forms of computer-based industrial espionage.
Even if there are occasional problems (there are always going to be untrustworthy organisations and highly determined hackers), the benefits would be inestimable. Even if compromised in one organisation, the approach would greatly slow down the spread of virus infections, in particular it would make accidental infection impossible. Most viruses would effectively die out, and virus protection software would be more easily maintained and kept abreast of epidemics. A determined and malicious dealer could not create a virus that would infect all computers. At present, anyone (whether a teenage hacker or an accredited dealer) can write a virus that will infect every PC, without restriction. If a hacker is not clever enough to write his own virus, there are plenty of books and bulletin boards where viruses (even 'virus construction kits') can be obtained. These sources of viruses would be rendered useless.
The author gratefully acknowledges the improvements to the presentation of this paper suggested by the anonymous referees, the editor, and by Andy Cockburn and Peter Ladkin.
1We use the term 'PC' to indicate typical personal computers and their operating systems, not just IBM-compatible PCs. We include 'workstations,' though the virus and piracy problem with workstations is currently less serious, partly because fewer hackers can afford them.
2Typically, they would use the same encryption algorithm but with a different key.
3In principle, a determined hacker could print an executable file on paper, and it would indeed appear unencrypted (albeit in object code). This enormous printout could then be OCRed back into another computer. A moment's consideration of the size of programs worth pirating, and the likely OCR error rate, suggests that this approach is not feasible.
[Back to index] [Comments (0)]