Software Based Security

Parent Previous Next

Software Based Security.

Most protection schemes focus on:

These security measures have been used for many years to distribute protected material safely, even when using insecure channels of transportation.

But how does these security measures perform, if the operating system (OS) has been breached by someone with malicious intentions - say a cracker?

1. Security by Separation.

Being able to separate vital elements - where each element can't reveal anything without the other elements being present - are very secure until they are assembled.

If a cracker has compromised the OS and has access to all the elements, security fails completely.

2. Security by Mathematics.

Using asymmetric keys for encryption and authentication, involving complex calculations on big numbers, can be extremely secure. Using RSA public/private key pairs based on 2048, 3072, 4096 or 8192 bit calculations are known to be virtually unbreakable for the foreseeable future - especially when using higher bit sized keys.

The public part of a key pair can be used for:

Vice versa the private part of a key pair can be used for:

However, if a cracker has compromised the OS and all cryptography is done purely in software executing within the OS, the cracker will be able to detect the secret private key in memory and security fails completely. The consequences can be absolutely disastrous:

Given the fact that public/private key cryptography does not fail well, it should be combined with other security measures.

3. Security by Obscurity.

In order to protect some material, one may use software that are protected by obscurity - designed to make it difficult for a cracker to analyze and modify the internal functionality.

If a cracker has full access to every part of a program, then it is theoretically impossible to prevent cracking. All secrets are available in some form or another, and given enough time and ingenuity a cracker will eventually understand every single one.

However, most crackers only have limited time and resources available for every program they attack. It is the usual cost benefit relationship which decides, whether or not it makes sense for a cracker to attack the software. In order to protect the software, the cost of cracking must be raised to an unacceptable level for the cracker.

Obscurity schemes are usually self-reliant. This makes them good candidates to be used in combination with other security measures. Furthermore they can implement a lot of unique obstacles, that may force the cracker to spend a lot of time doing statical analysis or runtime analysis - sometimes without getting anywhere.

The next pages within this chapter describe the probably most relevant obscurity schemes: