Advocating “Obscurity Pockets” as a Complement to Security. Part II. Deployment Scenarios, More Crypto-Primitives, and Obscurity-Pocket-As-Security

	Author:	“No Bugs” Hare Follow:
	Job Title:	Sarcastic Architect
	Hobbies:	Thinking Aloud, Arguing with Managers, Annoying HRs, Calling a Spade a Spade, Keeping Tongue in Cheek

In the first part of this article, we discussed quite a bit about the “Obscurity Pockets” in the context of our X-TLS (which is a “standard TLS plus 2 of ‘Obscurity Pockets'”), and their effects on increased diversity and potential to wreak havoc on the existing economy of hacking.

X-TLS Deployment Scenarios

“hey, how we’ll get the protocol unique?As a next step, let’s talk about the ways how our X-TLS could be deployed. The whole point of the X-TLS (and most of “obscurity pockets” – except, maybe, for Obscurity-Pockets-As-Security) is to have the protocol unique for each entity involved (where “entity” can be a “web site”, or “app”, or “server”, etc.). This raises a natural question: “hey, how we’ll get the protocol unique?”.

X-TLS as such doesn’t bother with answering this question; up to now, we were just assuming that we’ve already got our Client app to the end-user somehow – and that our Client app is uniquely tailored to our Server app; in other words – Client and Server have the same Obscurity Pockets, but their Pockets are different¹ from any-other-Obscurity-Pocket out there.²

Generating such Client+Server apps is trivial; placing Server app to our server is trivial too; the only tinsy problem remaining on this way is “how to get our Client to the end-user – and how to do it securely too”.

To answer this question, first of all, let’s note that these days, there are three primary deployment scenarios for apps: (a) direct downloads to desktops (yes, it still happens), (b) App-Stores and (c) web. Let’s consider answering “how to get our Client to end-user” question in each of these scenarios.

¹ At least “statistically different”

² BTW, as a very nice side benefit – such tailored app will allow our Client+Server to use the only-latest-greatest-TLS (eliminating all the downgrade attacks) – and with the only-latest-greatest-cipher-suite enabled too

Direct Downloads and App-Stores

With app stores, delivery of our Client to end-user is simple: just sign our app – and put our app to the appropriate app store. Signature of our app will be validated on the device – so end-user will not only get our app, but also will get a guarantee that it is indeed our app.³

BTW, pretty much the same logic can work for downloadable desktop apps. While signatures for downloadable apps are not mandatory at least on Windows – there are still mechanisms to sign the app and to validate the signature too. Moreover – last time I’ve checked, browsers did help the end-user with making this validation (complaining about unsigned apps much more loudly than about the signed ones).

“Such signed apps are actually the best case for our X-TLS: as long as we can trust signature validation – we can reap all the benefits of the X-TLSSuch signed apps are actually the best case for our X-TLS: as long as we can trust signature validation (and as a Big Fat Rule of Thumb™, signature validation is orders of magnitude more trustworthy than TLS etc.⁴) – we can reap all the benefits of the X-TLS (that is, including additional resistance even to Heartbleed).

³ This assumes that the end-user pays attention , but this assumption is unfortunately inevitable for any real-world deployment scenario anyway.

⁴ there are at least two big reasons for it: a) for app signatures, private key can (and SHOULD) be taken offline; b) attack surface for signature validation is at least 10x smaller than that of TLS

Web Deployments

With purely web deployments – given current browsers, the situation is more complicated (and admittedly less secure).

We’ll still produce a pair of Client-Server apps with matching Obscurity Pockets (with Client app being a JavaScript – and we’ll discuss below, I’ll strongly argue for using LLVM+emscripten+asm.js to produce the Client app). But we’ll still need to deliver our JS-based Client to the end-user – and in a secure manner too.

Current problem of X-TLS (and obscurity in general) with web deployments is that initial download of the app itself will rely on TLS for security; this pretty much means that if there is a serious hole in TLS (such as Heartbleed) – then initial download won’t be secure 🙁 .

Still – even with current state of web browsers (which don’t know anything but TLS for security) – X-TLS would help against a wide range of attacks on TLS, where the attacks are affecting only confidentiality, but not integrity. Recently – there were quite a few such attacks on TLS (from padding oracles and derivatives – to CRIME etc.). And as long as these attacks don’t affect integrity – and as long as the only thing going over TLS-which-is-not-X-TLS, is initial download of the Client (which is not confidential to start with) – we’re fine, and X-TLS can do its job.

On the other hand – to make sure that X-TLS can increase attack costs, given attacks such as Heartbleed being present – we’ll need browsers to support a concept of “signed JS apps”. Such a feature, BTW, would be a Good Thing™ regardless of the X-TLS and obscurity – at least because, as discussed above, signatures inherently provide significantly better security than downloads-over-TLS.

X-TLS Deployment Summary

To summarize the discussion above:

X-TLS is all about having Client and Server which work with each other (and nobody else)
With signed apps (app-store and downloadable signed ones) – it is easily achievable
With web apps – and with current browsers relying on TLS as the only security measure it means that if TLS integrity is compromised – then Client download can be hi-jacked even before X-TLS has a chance to come into play. On the other hand:
- Even with current browsers, X-TLS still greatly increases the exploit costs for those TLS vulnerabilities which are merely compromising confidentiality.
- I am arguing for introducing signature validation for JS apps into browsers too (which is BTW a Good Idea™ regardless of obscurity). With it in place – security of web-based JS apps will become more or less on par with the security of downloadable apps.

On Other Crypto Primitives

Up to now, we discussed applying Obscurity Pockets to one single crypto-primitive: crypto-protected streams (using TLS and X-TLS as an example). However, the concept of Obscurity Pockets is certainly not restricted to crypto-streams.

BTW, let’s note that I’m not claiming that all the Obscurity Pockets below⁵ are flawless: there can be significant implications which I am missing (hey, even Bruce Schneier had more than one version of his Lemma on cascaded crypto – and I am not him by far 🙁 ); still, (a) they should be a reasonably good starting point for further discussion, and (b) I am sure that with some relatively minor tweaks, these Obscurity Pockets below can be made secure.⁶

⁵ Or above, for that matter

⁶ at least, “external” pockets seem to be quite secure without much additional tweaking

Obscured Symmetric Block Crypto

For block crypto, I can see both “internal” and “external” Obscurity Pockets; to make security a bit simpler to reason about, I’d say that both these Obscurity Pockets MUST be bijections operating on one block of the underlying crypto. And as with the X-TLS – their respective state MUST be constant (which effectively reduces them to scrambling – for the time being, that is).

Still, as long as these requirements (plus the requirement for the “internal” Obscurity Pocket to have time of scrambling one block independent on the data within – to eliminate time-based side-channel attacks) stand – such X-Crypto will be at least as secure as the underlying symmetric block crypto.

Formally, for “internal” security pocket to be at-least-as-secure-as-underlying-crypto – we’ll need to rely on an assumption that underlying block crypto is “good enough” and can securely encrypt any plain text (and for any block-crypto-used-in-practice we’re relying on this assumption all the time anyway). This assumption effectively removes the problem of the order of ciphers highlighted in [MaurerMassey].

If we want stronger guarantees, we could combine our “internal” Obscurity Pocket with our underlying cipher via technique from section 15.8 from [Schneier] – which is formally provable to guarantee the best of both ciphers – and without any assumptions that underlying crypto is “good enough”.

“when speaking about “external” security pocket – we can simply rely on proof in (MaurerMassey), without any further reservations.BTW, when speaking about “external” security pocket – we can simply rely on proof in [MaurerMassey], without any further reservations.

Obscured Symmetric Stream Crypto

For symmetric stream crypto (the one which XORs the data with a stream) – things are even simpler. We could use our own bitstream to XOR with the output (or input) of the underlying stream cipher – and according to Corollary 1 from [MaurerMassey] (and taking into account that XOR is associative), such a combination is at least as secure as the underlying stream cipher.

Examples of fast-but-not-necessarily-secure bitstream generators comprise all kinds of PRNGs, including anything from linear congruential ones, to AES in CTR mode (with a pre-defined key), the latter being very fast but crypto-secure too. As bijections over this stream (at least before XOR-ing it with the data) are allowed without the risk to weaken security – we can easily build Pocket Generator for stream crypto too.

And as soon as we’re satisfied that our Obscured Crypto (either block one, or stream one) is at least as secure as original crypto – we can use this Obscured Crypto pretty much as a drop-in replacement for the original crypto; in particular – we could use it as a TLS cipher (NB: exact restrictions for such usage to be secure, may require separate analysis, and are beyond the scope of this article).

BTW, one additional thing to note in this regard – is that using Obscurity Pocket at the TLS level doesn’t prevent using a different (and independent) Obscurity Pocket at crypto level (which then will be used by TLS); these Obscurity Pockets affect different layers – and are aimed to mitigate different vulnerabilities.

Obscured Hashes

Crypto-hashes, as a rule of thumb, are used as a kind of one-way function – i.e. they’re sufficient to check that the data is the same – while it is not possible to reconstruct the data itself.⁷ With this in mind, we can easily add pretty much the same “internal” and “external” Obscurity Pockets; as long as both are injections (with calculation times being independent from the data) – the result will be at least as secure as the original function.⁸

While this technique won’t fly for signatures (at least for those that need to be publicly proven to be valid) – it may come handy for usage scenarios such as password hashes: if the attacker has got the DB of password hashes but hasn’t get the Obscurity Pocket – well, he’ll be out of luck extracting the passwords (and if he got the Obscurity Pocket – he’ll be in no better position than if we’d not add any obscurity at all).

⁷ Well, except for brute force – and brute force can be very annoying in some scenarios such as password hashing

⁸ once again, for this to stand for “internal” pocket we’ll need to rely on underlying crypto hash being “good enough”, but for “external pocket” there is no such assumption

Obscured RNG

One interesting case for Obscurity Pockets is… obscuring an RNG.⁹ In particular, we can add the Obscurity Pocket for an RNG – just allowing Obscurity Pocket to produce its own bit stream, and make a XOR of two bitstreams within the “obscurable” X-RNG to produce output bit stream.

One very important property of such an Obscurity Pocket is that

If we’d use a reasonably good Obscurity Pocket for our key generation – then even in the case when underlying RNG is completely insecure – our keys will still be secure.

In the spirit of Security-by-Obscurity, this stands when our Obscurity Pocket is not known to the attacker; however, we can get a bit further and say that there exist such Obscurity Pockets which provide additional security even if they are known to the attacker. One very practical example would be to have our Obscurity Pocket for RNG being a crypto-level PRNG (say, based on AES in CTR mode) – with a key obtained completely independently (using the data from key input timings, from user input, from random.org, etc.). After this setup is completed – our Obscured-RNG would be still secure even if standard RNG is completely predictable (which is exactly the thing which happened with Debian – and caused tons of trouble).

“In other words – such an Obscured RNG would protect us from Debian RNG disaster(!)In other words – such an Obscured RNG would protect us from Debian RNG disaster(!).

Obscurity Pockets As Security

Actually, our last Obscurity Pocket (the one for RNG) can be seen not as an Obscurity – but rather as adding real security (two independent XOR-ed RNGs are secure if any of them is secure). This concept can be extended further – into more generic practice of using real additional security within our Obscurity Pockets. This means: while Obscurity Pockets do not require the contents of Obscurity Pockets to be secure – they don’t prevent it either.

In other words:

Using exactly the same API as the one discussed for Obscurity Pockets – it will be possible to build real multi-layer security.

Overall, Obscurity Pockets as Security is quite a complicated subject, and I don’t feel ready to speak about it in detail right now; however, there are a few preliminary observations in this regard:

To enable Obscurity-Pockets-As-Security – we’ll need to relax our requirements a bit; it is perfectly possible (for example, for ciphers – it can be done based on Chapter 15 in [Schneier] and/or [MaurerMassey]), but right now, I am not ready to specify these requirements in detail.
- Of course, keys being absolutely independent, will be a requirement – but unfortunately, it won’t be the only one.
On the other hand – Obscurity Generators won’t be able to generate Obscurity-As-Security.
- However – Obscurity Generators MAY be still used to provide additional Obscurity (such as “a layer of obscurity between two crypto algos”), making each communication unique.
- Also – a different kind of Generators (should we name them Security Generators?) might be able to use several crypto-primitives (plus maybe some Obscurity) to generate a multi-layer crypto-primitive. For example, a Security Generator may use a dozen of more-or-less reasonable block ciphers (with AES finalists coming to mind) – and may combine them in a random manner. Breaking such a “sandwich” will be extremely difficult even if exact used algos are known (and if one of the algos is completely broken¹⁰) – and will be perfectly unbreakable if the order of the algos is not known.
  - Whether being “perfectly unbreakable” is a good thing or not – is a subject for a separate debate.¹¹
On the third hand (did you know rabbits have three hands?) – API for Obscurity Pockets (as in “functions to be called”) – can stay exactly the same as for purely Obscurity use; it means that the same implementation of “obscurable crypto” (such as X-TLS) can be used to support both Obscurity Pockets (with Pocket Generator) – and Obscurity-Pockets-As-Security

“such a protocol (if properly deployed on the Server Side) – would defeat Heartbleed too (even if all the details of the Client are known)One IMO very practical example of such Obscurity-Pockets-As-Security, would be to have two-layered crypto channels (one within another one): for example, it can be an X-TLS (as described in Part I), using SSH within its “internal” Obscurity Pocket. Moreover, such a protocol (if properly deployed on the Server Side) – would defeat Heartbleed too (while in absence of X-TLS “external” Obscurity Pocket, Heartbleed would be able to compromise X-TLS – it wouldn’t be able to get through SSH – even if all the details of the Client are known).

Oh, and BTW – adding further scrambler between the two crypto layers (and outside them too) – wouldn’t really hurt either (at least because it would make the system unique, which, as we discussed, would break typical patterns within hacking community). In addition, it might help even against government-level adversaries – as long as they cannot get their hands on the obscuring code.

⁹ Whether “Obscuring” is a proper name for RNG – or if it is an instance of “Obscurity as Security” discussed below, is debatable, but terminology is not what I really care about now

¹⁰ Strictly speaking, it is not guaranteed if the 1^st algo in the chain is broken, but in practice – it is more than likely to stand

¹¹ TBH, personally – I’d rather not have any access to any really important information which is protected with an unbreakable crypto, as to break it, the only way will be to get me personally – thanks but no, thanks

To be Continued…

In Part III of this mini-series, we’ll proceed to the question of “how to obscure things in the best possible way”; while not 100% necessary for Obscurity-Pockets-As-Security – it is all-important in case when using Obscurity Pockets just for improving diversity of the protocols (as we discussed in Part I).

[+]References

Acknowledgement

Cartoons by Sergey Gordeev from Gordeev Animation Graphics, Prague.