Moving Target Defence: Security, Resilience and Obfuscation

A standard method that an army will use is to create a moving target, and which confuses an attacker. This might relate to change the…

Moving Target Defence: Security, Resilience and Obfuscation

A standard method that an army will use is to create a moving target, and which confuses an attacker. This might relate to change the movement of troops on a continual basis, or in the location of missile bases. With this, a static target can often be analysed in great detail, and then probed for its operation. With a moving target, an adversary will often spend a good deal of their time understanding and reanalyzing. As they do this there’s a good chance that they will be detecting in their spying operations.

An army, too, needs resilience, and where there is no single point of failure. Perhaps there is an army deployment base, and where the troops are shipped to. If an adversary finds out that all the troops are deployed from there, then they could attack that base first, and then look to attack other parts, as troops could not be deployed other different areas of the battlefield. An army would thus have plans to have alternative deployment bases, and also for the fast creation of one within a different area.

And so, let’s say that you had a Web site. Today it uses Microsoft ISS running from Amazon AWS, and then the next day it was running Apache within Microsoft Azure, and the day after it used nginx within the Google Cloud. Each instance of the Web server and all its services are continually changing too, with different IP addresses, and different implementations of the code within the browser. This would confuse an intruder, as they just won’t be able to focus in on one implementation, and would spend their time trying to re-learn and re-scan. And if it was all fairly random in its changes, it would make it even more difficult, as the intruder would never know when things were about to change, and what they were going to change to.

In the cloud, and in dynamic systems, this changing and reconfiguration are all natural things, as we often script our infrastructures, and dynamically respond to changes in the environment. This type of approach not only helps to confuse attackers, but also improves resilience, as the infrastructure never dependent on one thing, and is forever moving around. A failure of one element can then be easily replaced by something else.

And so a new type of security defence is being applied to information systems: MTD (Moving Target Defence). This aims to reduce the opportunities for intruders to do damage within a data infrastructure, and has three main classifications:

Shuffle. With this we organise the system architecture into a number of layers, and then shuffle these. This can have layers of different IP address ranges or topology arrangements. We could then shuffle our stack, and bring different deployments in. SDN (Software Defined Networks) provide many of the tools we can use for this.
Diversity. With this we implement a range of implementation methods in order to confuse an attacker. These might vary the operating systems used to change the stack elements. We can also make sure our data can take different routes through a system.
Redundancy. This is where we use a range services, paths and nodes in order to create our services.

An application of this is to split data up into fragments (n shares) and then distribute them over different cloud systems. We can then reconstruct from t shares. This is a t-from-n sharing system. In this way we get both security and resilience, and one cloud could fail, and we would still be able to reconstruct the data:

With the CryptoMove product, the data is fragmented up and then these fragments are encrypted around the network infrastructure. A key element is that these fragments are then continually moved so that they never stay on the same Cloud server for any considerable length of time. In this way, an intruder can become confused with the infrastructure as the data is continually moving. The system also uses a redundancy mechanism and where data is split into secret shares with a t-out-of-n policy, and where m shares are created and that n shares are required to rebuild the data back.

Splitting shares with Elliptic Curve Methods

Our data structures are often not secure, and these are especially at risk when we use public cloud systems. Along with this, we become highly dependent on specific cloud systems. Over the past few years, all the cloud infrastructures have had significant outages, and thus we need to build-in resilience into your data storage, and where we can cope with an outage.

In our data centres, we often use RAID 10, and where we stripe and mirror data across disks, and where a failure of one or more disks does not lose any of the data. So can we re-create this type of system without our Cloud-based architectures, but still be ultra secure? The answer is yes, and I’ll show you a method which achieves this.

Threshold schemes

A threshold scheme allows us to create a number of secrets and then define a threshold number of the shares to come back together again. If we have n shares we can define that t shares need to come back together to reconstruct the original data.

What we want is for Bob and Alice to generate a key pair (either for the session or long-term keys). They will then pass their public keys to each other, and at the end will have a shared key. This key is then used to secure each of the shares:

Generating a shared key with Elliptic Curve

The starting point of the method is for Bob and Alice to agree on a shared key. For this Alice will create a private key (a) and Bob will create his private key (b). Each of them will then generate their public key with aG (mod p) and bG (mod p), and exchange these values:

Generating and reconstructing the shares

Next Alice will split a secret message (m) into a number of secret shares (n) and which have a threshold of t. She then converts each of the shares into points on the elliptic curve with Pᵢ=mᵢ+abG:

These points can then be passed to Bob. He will take t points and then compute m ᵢ=P ᵢ−abG [demo]:

A sample run is for a threshold of 2 and with 4 shares is [here]:

===================================
Elliptic curve: SECP256k1 Parameters
G_x= 0x79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798L
G_y= 0x483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8L

Order: 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141L
===================================

===================================
t: 2
n: 4
===================================

===================================
Original key 0x1b39b5771afbe1a01928e87c957a55a9681586f836593b7ad63f5cf5cbc85576L
===================================

===================================
Share 0x3defd23c1ec75f353d9917e9c12f78270ae74f589ad00e030935c0f4f2cbaa6L Verified: True
Share 0xec8444d068dd0a468e8a3a80a2ab995a33f63fd98c4966814ab9b9b5a2c76117L Verified: True
Share 0xd5298c7d0fcd9e99c93ae382a9443b333c8f2dd6df9d2be6a50db8cf262bc647L Verified: True
Share 0xbdced429b6be32ed03eb8c84afdcdd0c45281bd432f0f14bff61b7e8a9902b77L Verfied: True

===================================

Reconstructed key: 0x1b39b5771afbe1a01928e87c957a55a9681586f836593b7ad63f5cf5cbc85576L
===================================
Original message: 5555
Reconstructed message: 5555.0

Conclusions

The industry is buzzing with MTD, and it is a method which makes increasing sense. For many, it should be a methodology that is integrated into the development and deployment phases, and where we design systems to be dynamic in the way they run. With this, the system never settles down in the one place and doing the one thing. This can be natural, as our vertical stacks are often split into different technologies. Increasingly we need to diversify our stacks and have different methods used in order to confuse an adversary.