Encryption has been used for many years to prevent unwanted access to information. Many such systems have been considered unbreakable - still weaknesses have made decryption (also called deciphering) possible.

The existing theory has been built around the typical military situation - two persons are working together at a distance, the intruder is listening and can see the transmitted (encrypted) data. For security of mass-produced and widespread items, the situation is somewhat different.

The following notes are from a lecture held by Hans K. Pedersen, CEO and co-founder of Link Data Security.

Traditional military:

Only sender and recipient have key. Recipient is your ally.

Public key:

Only recipient has private key. Recipient is your ally.

Secure mass distribution:

Intruder can get key. Recipient may be your enemy.

We want to prevent

   Theft
   Unauthorized access
   Use beyond intended amount/timeframe 
   Disassembly/publication
   Modifications

Without

   Restricting the legal user too much.

LOCKING DEFINITIONS:

OBJECT:	Item that is access or theft protected.
LOCK:	Limits or blocks object if key is not present.
FIX POINT:	Anchor point that object is locked to.
KEY:	Portable unlocking condition – can be a code.

Three types of protection:

Objects:

Keys:

Fix Points:

PROTECTION OBJECTS:

Definitions:

DATA:	Any collection of binary numbers
Installation:	Process which activates Program or Data.
Program:	Binary numbers understood by the CPU as instructions (i.e. an executable program).
Data:	Digital information, such as text or graphics.

lnstallation protection:

The installation process is locked to a key. In other words the installation program is protected. After installation, the application is usually unprotected, but another and safer approach is that the main program remains protected and locked to the machine it was installed to.

Program protection:

One of the program modules is protected. This process involves three things:

• A GUARD module is included, internally or externally.

• The program has been modified to give CPU control to the GUARD module.

• Program secrets have been hidden by ENCRYPTION

The GUARD module verifies a chosen CONDITION. This can be done in three different ways:

1) Upon entry.

2) Upon calls from the program code.

This solution is safer, but requires changes to the source code. The weak point is the program code being unencrypted and open for debugging.

3) A combination of the above two.

This is the safest solution.

Examples of a CONDITION:

Data protection:

Data is always associated with a program that can use or show the data. This program is called a Viewer, Browser, Reader or Player. The guard module is normally not connected to data directly, but added to the Viewer.

The Viewer can be a proprietary design, made for the purpose, but it is often of a generic nature - cannot be modified and is available unprotected from other sources.

If the data is generally usable, it must be encrypted. Hence the Viewer needs a decryption module.

Please read more detailed information in Data Protection in a Nutshell

CODE SECURITY:

This term covers techniques that protect the guard module and the program code against:

Code security is a kind of access control, allowing normal program operation, but not inspection or slow execution (single-stepping) of the program. No fix point. Real-time execution is the built-in key.

Code security is a weak link in ANY form of protection. It is targeted against specific tools and techniques used by hackers and crackers and may include systematic encryption of pieces of the program code which are "opened" and "closed" when needed.

Such a code-secured module is sometimes called a "Tamper Resistant Box" (TRB). Even if access to the inner code is secured, at some point the code must be readable for the processor. At this point, it should be made difficult to save the code for later inspection.

ENCRYPTION:

Three types of intrusion attempts:

1) Cipher-text only

This is the most difficult case to break, since the intruder doesn’t have any idea of how the final plain-text will look.

2) Known plain-text

In this case, the intruder has an example of cipher-text and the resulting plain-text. This makes it easier to guess, since a correspondence may be established. For mass distributed items, you should count on this as the typical case.

3) Chosen plain-text

With program and data protection, this case is not relevant, provided the publisher keeps his encryption tools safe.

Demands for high security

• A high degree of code security in the decryption module.

• A decryption key having a sufficient number of bits.

• A high quality algorithm.

ASYMMETRIC ENCRYPTION:

This concept from 1976 uses a different encryption and decryption key. It is also called public/private key, as one key is available to the pirate while the other is not.

For most copy-protection use the decryption key is by no means public, it is supposed to be guarded well inside secure code. If a pirate should find the decryption key, he would never use it for encryption purposes.

However in some special situations we want to prevent encryption even if decryption key has been found:

1) Access-Code entry.

Even if one pirate determines the decryption of an Access-Code, we don't want him to be able to make a generator that can be used to create Access-Codes for other installations. This is known as a "keygen crack".

2) Original Data Creator

Besides securing the publishers copyright and profit, encryption can also be used to prevent unauthorized publishers from making additional data files. The asymmetric encryption thus ensures the validity of the distributed information; nobody could have added or changed information.

3) Original Code Creator

Using special processor hardware with built-in asymmetric decryption of any executed code, the manufacturer can make sure that only approved code will run. In this way virus and similar malicious code can be prevented - and license income for legal programs can be assured. Both Sony Playstation II and Microsoft Xbox use this technique.

OS OVERVIEW:

Applications run at the highest level, hardware drivers at the lowest level. Code security should be placed at the lowest possible level to be able to trap attempts to debug or to emulate the PC or any physical key.

Modern Operating Systems, however,prevent normal users from access to the lower levels. A more practical approach is to let the protection system detect the presence of any such low level debugger or emulator and refuse to run if found. This is necessary if the program has no installation or can be installed by less privileged users.

Machine-locked programs (computer is fixpoint) need to differentiate computers from other similar ones. Here it is also best to aim at the lowest level - for security reasons but also to make the system robust against OS updates. As it can be difficult to find even hardware items that are not upgraded or replaced, a good algorithm must use a balanced weighting scheme.

NETWORK SECURITY:

On a network we want to restrict:

• Access using password or machine ID.

• Theft by locking to fix point, e.g.
  server, user machine, network card, SysOp machine.

• License violations, e.g. no. of simultaneous users.

Often the revenue from network products in itself cannot justify the costs for network protection, but releasing the product unprotected for network use most likely will spoil any protection made for the single user version.

A good network protection shouldn't interfere with normal back-up operations and should also allow server upgrade or replacement.