I do not mean either transport or snake oil.
DRM has been a bust because two problems were conflated
1) Limiting access to confidential documents to those with a need to know
2) Preventing disclosure but those granted access.
The first is a completely tractable problem of cryptographic engineering
that I have a working, almost open (November) solution for with MIT License
reference code.
The second is never going to have an absolute solution. Even with
trustworthy hardware, there are techniques that can break a device if you
are prepared to pay a lot of money to do so. Techniques that involve
electron microscopes and sanding down the back of devices. Even FIPS-140
level 3 are not absolutely immune.
But this disclosure would probably have been prevented with (1) alone and
almost certainly with (1) plus pervasive accountability controls. Which
incidentally, Mesh/Recrypt does support.
I want to establish an international norm that cyber commands secure their
attack code end to end and I am proposing an infrastructure that does
exactly that.
Now the utility of such a scheme embedded into Office, OfficeLibre and the
like would be vastly wider than just cyber commands. But one of the
pathologies of the US government research funding programs is that the only
work that can be funded is work that has a military application. So I am
framing the problem in this form for the benefit of DARPA program managers
looking to give me money to work on this.
I call my subset of the DRM problem Confidential Data Control. The
introduction of 'rights' into the problem statement is entirely spurious.
Right now, the crypto code works in Ed25519 and will probably work for
Ed448 by this evening. Getting it to work on Montgomery curves is a little
more complicated as I have to figure out how to do point addition as a
primitive separate from multiplication. If someone could shoot me some code
to copy, it would help me save a few hours and spend some quality time with
my daleks this evening.
On Fri, Mar 10, 2017 at 9:27 AM, Michael Richardson
<mcr+ietf(_at_)sandelman(_dot_)ca>
wrote:
Phillip Hallam-Baker <phill(_at_)hallambaker(_dot_)com> wrote:
> However, it is not just the US agencies doing this work. There are
now
> 117 cyber commands and there is a real problem of 'loose
> cyber-weapons'. It is to the interest of the US and to all the other
> cyber-commands that a norm is established that cyber weapons are
> secured end to end throughout their lifecyle and tools produced to
> enable that to be achieved.
I'm not really sure I understand what it means to secure a cyber weapon.
You could be talking about keeping the source code in locked briefcases,
or you could be talking about some kind of snake-oil DRM on the binaries,
like the movie and game industries thinks they have "invented". Or
something
else completely.
> Such tools do not currently exist. However some key patent expiries
> that have occurred and will be complete in November this year make
true
> end to end data level encryption practical. I have proof of concept
but
> short of infringing code running in the lab which I will push out as
> soon as I can together with the supporting specifications.
Now here you seem to be talking about securing things in transit.
if I may air some of my griping: tcpdump has recently dealt with some
hundred
potential vulnerabilities found by futzing. I was interested to find a
file
called "PCAP" in the Vault 7 archives, but it's not really released yet.
What's annoying is that there is money for attack tools, and there are
rewards for finding exploits, but not much for fixing bugs, and many
serious
disincentives to good design in the first place.
--
Michael Richardson <mcr+IETF(_at_)sandelman(_dot_)ca>, Sandelman Software
Works
-= IPv6 IoT consulting =-