Monday 13 August 2018

A Design Challenge for Horologists

I have a strong interest in non-electronic computers as an educational tool. It remains as useful today as eleven years ago, when I published a letter to the editor in the January 2007 issue of the British Institute of Horologers. An horologer is someone who makes mechanical clocks and watches, and horologers definitely don't believe in electronics.

Everyone can benefit from the principles, but lawyers, politicians and anyone who cares about privacy and law enforcement really needs to understand this. The law defines what can and can't be done with a computer, and to some extent it even defines what a computer is.

I think one of the best ways to picture the essence of a computer is to have one in your hand without any electronics.

As some background, on my desk I have this little beauty:



It can store numbers and do long division and multiplication - turn the handles, push the buttons, ding! But despite being an essential tool of business for a century, it's only a calculator, not a computer. I picked it up in a flea market in Helsinki :-)

My hand-operated calculator:
  • would not meet most legal definitions for being a computer. It can't store a list of instructions, and its programming (long division implemented in cogs and levers is still a program!) cannot be changed.
  • would, when in use, meet the legal definition for processing personal data under the GDPR. I could use it to add up your expense records for the month, and the amount of the last expense and the total of all expenses would remain stored and readable in the machine when I finished. (I seriously doubt this calculator would be used to cause GDPR breaches! But it is important to understand the principle of these definitions.)
In order to be a computer, it has to have a decision system capable of reading a programme and executing it, or what we would call a CPU in an electronic computer.

The Babbage Analytical Engine was a full mechanical computer designed in 1837. The design has been demonstrated many times since to be workable, and there were even programs written for it by Ada Lovelace. She was the first to realise the Difference Engine was much more than a calculator.

The 1937 Z1 computer, built in a small home in Berlin, was a fully functional mechanical computer, using electrical motors to turn and move the components:

Image result for earliest mechanical computer Z1
The Zuse Z1 computer
It was soon destroyed in bombing raids, but the Z1 was the first recognisably modern computer.

In a talk I do about "What is a Computer?" I usually play this clip from the US Navy showing their mechanical fire control computers. This is (a) fascinating and (b) a reminder that typically computing advances are first used to do a better job of killing people.

... and all that explains why I wrote in the January 2007 issue of the British Institute of Horologers! I got several replies from horologers (real actual clockmakers!) but didn't achieve my goal. I have made some progress though. What I really want to see exist is an actual working clockwork computer that performs useful tasks we can recognise from today's world of computing. It's clearly feasible.

And here's my letter:



A Design Challenge for Horologists



January 22, 2007
Dan Shearer


Until this month I hadn't even heard of horology. I'm a computer scientist, occupied with what people do with electronic technology and software, and what they do to people. Over the years I'd seen clocks in museums piece, marvelled at the old navigators, and once I read an article on apprentice horlogers in Geneva. But after meeting some lawyers recently I realised I had to learn about watchmaking.

Here is the challenge:

I need to design a fully clockwork computer. The computer must be a work of horology, not merely mechanical engineering. It must function recognisably like a familiar electronic computer, accepting commands from a keyboard to run programs and display results on a screen.

This article explains my motivations. As I did the research, I realised that with probably just two advances in horology such a design could become reality. I wrote a second article discussing in more detail the practical implementation issues involved.

A Computer? Why?

Like everyone else, I'm affected by laws involving computers. Laws tell me what I'm allowed to do with a computer, and if I become a victim of computer crime I need help from the law. But the more lawyers I met the more I realised I won't get the help I need if the people in the legal system can't even recognise a computer when they see one. More broadly, we live in an age where computers surround us, often invisibly – and computers process data, data that can clear me or convict me, save my life or endanger it. It is a trifle worrying that the individuals who can care for me or accuse me, educate, defend or prosecute me are likely to overlook computer data involved since they're thinking “oh, a kind of beige box with a keyboard and screen”. How are they to realise that the laws governing the computers in their life affect them hundreds of times a day?

So I started looking for an unforgettable illustration. Something to show a computer is a thing that does computing. It doesn't even need electronics, let alone a beige box. That's what lead me to clockwork. There is something homely and understandable about machinery that goes 'tick-tock', in contrast to the seeming magic of electronics. I want people to think about the notion of computing rather than a computer.

My new UK passport contains a computer too, programmed (as shown by The Guardian) to give all its information to anyone that asks, without a password. If the chiefs of the Home Office understood that the new passport was as much a computer as their own laptops, might they have given their computer experts better instructions?

Horological View of a Computer

A computer is any device which can:

  • obey instructions (e.g. add 48 every 1 time the instruction occurs)
  • store a list of instructions (e.g. add 48 this time, then 36 next time, etc.)
  • receive and remember information (e.g. when someone turns a winder)
  • decide which instructions to do next, and when to accept information

Except perhaps the last point, the list (and the numbers) should be familiar to horologists. It describes a stored program computer, something computer science calls a Von Neumann Architecture. We'll look at components of a Von Neumann-type machine, and how they might be viewed in terms of mechanical devices. One of the most striking things is that horology already comes close to a lot of the functionality/

Input – A device that receives information, maybe from a human. Examples: Someone typing on a keyboard from a manual typewriter. The information might be in response to a question (“How old are you?”).

Output – Makes information available directly to humans by displaying it somehow. Most like a traditional computer would be interactive screen output via a split-flap board, like most railway stations used to have (remember the flick-whirr when it was updated?) Typewriter output on paper would be another option.

Memory – For storing information so it can be accessed later. The basic unit of information in computing is usually an “on” or an “off”. So if you want to store the word “Clock” it gets translated into a series of ones and zeros, which are then stored by on/off switches. Horologists know all about programmable switches, which mean “if the switch is set then take one action, if it is not set do something else”. The extra twist is to have a way of detecting whether the switch is “on” or “off”. The ability to detect switch setting is called “reading memory”. Once you can do that it is a matter of having a lot of these readable switches to give the computer a reasonable amount of memory. With these two issues solved, the ones and zeros corresponding to the word “Clock” can be written to memory by setting and unsetting a series of switches, and later read back.

Arithmetic and Logic Unit – For doing operations with numbers. Older readers will remember mechanical adding (or calculating) machines that were manufactured in quantity up until the late 1970s, a centuries-old idea. Besides adding, multiplying etc. there's one or two other operations but none of these should be technically difficult to design from a horological point of view.

Control Unit – Executes lists of instructions, or programs. Probably the only component that doesn't have anything in common with horology (as far as I know so far!), this unit directs the flow of events. For example looking up a number in memory and telling the Arithmetic and Logic Unit to add 48 to that number, then store the result somewhere else in Memory, or maybe Output it. The Control Unit is the real brains of the show, and is in charge of executing programs.




The Missing Magic

Having these components of a notional computer are all very well in theory, but they aren't quite enough for a useful computer. Computer science has come up with some ways of tying them together, one of which is straight out of horology.

Bus – An information channel between the foregoing components. Implementing this in clockwork will require some ingenuity. In a silicon computer the Bus is like a copper wire linking the memory, control unit and so on, allowing electricity to travel between them. With horology we need to get information (such as the word “Escapement”) from the Memory to the Output, or from the Control Unit to the Arithmetic and Logic Unit. An example (but I don't necessarily suggest feasible!) way might be to have an oscillating central bar containing whiskers that can be pushed in and out to indicate different values, where the whiskers are adjusted by levers immediately next to the levers used to read the values and each oscillation moves the location of the whiskers from the setting levers to the reading levers. I'm not covering implementation challenges in this article, but its worth reflecting that Bus speed is a vital issue for how practical this computer will be.

Clock Signal – a single master beat that is used to synchronise all other activity in a computer. If we're fetching information from Memory using the Bus or a performing a calculation the Clock Signal is the only way of making sure we're not tripping over ourselves by using the wrong number, or the right number twice etc. Increasing the speed of the clock signal – assuming all the other components can keep up – is one way of speeding the entire computer up.

Storage – Like Memory, but lasts longer and is usually bigger. A mechanical equivalent of a filing system. You put information in and can get it back out when you want it. A storage system can be punched cards, or pianola-like punched paper rolls, or small plastic cards with very fine ridges and dips after the style of a music box's data. There have been storage systems in use since early days of the industrial revolution, and I'll be surprised if there isn't at least one horological tradition of using them somehow!

The Other Reasons Why

A clockwork computer may actually be useful for reasons other than educating Her Honour.

Physical Longevity. We have a good idea what happens to clockwork after a few hundred years, but there are real question marks surrounding all forms of silicon computers. Nobody really knows what happens to transistors as the centuries roll by, and if you need a computer for a simple task such controlling the doors in an long-term nuclear waste storage facility perhaps a clockwork might be better. Watch making techniques and materials can produce such tiny and reliable systems that they may be worth considering for these tasks.

Physical Robustness. There are a few physical environments where intense radiation makes electronic computing inherently unreliable. For very simple tasks, might clockwork computing be useful?



Micromechanics. A lot of research is being put into machines made of components that are truly tiny. Scientists are creating gear wheels that are a comfortable size for an ant to pick up, and have been experimenting with tiny geartrains, levers and so on since the 1980s. This is a very practical field of research and there are results in production now. One of the interesting things about micromachines is that they can often be mass produced using photolithographic techniques. A practical design for a clockwork computer might be able to be applied at this scale of engineering. I am cautious because friction is more important in microengineering rather than less, but perhaps some of the other physical effects may compensate such as inertia with high oscillation rates.

Conceptual Longevity. A generation of silicon-based computing equipment lasts maybe two years before becoming obsolete. When communicating with far-distant generations, maybe it might be wisest to provide the design for a conceptual clockwork computer and then the programs that can run on that, rather than anything electronic. Nobody has ever built a Babbage Analytical Engine (see the next article for more about Charles Babbage and his mechanical computer from two centuries ago) but there is a computer simulation of capable of running programs written by Babbage and his students. A communication consisting of a series of computer programs accompanied by schematics of a physical computer that will certainly run these programs is an extremely clear communication. Any technically sophisticated person would merely implement an emulation of the computer rather than the actual clockwork, but they will have no difficulty understanding the design because it is simple mechanical principles.

Conclusion

Why horology? I could have approached robotocists, who spend their lives at the mechanical end of computing. But I think a robotocist has rather too much silicon thinking already, and besides they like to use hydraulics and other very clunky techniques. I can imagine a competer without electronics that is as incomprehensible in its design as any silicon computer! Using techniques of robotics seems as far from horology as Babbage's mechanical engineers. I want that 'tick-tock'.

I'm also intrigued by my reading so far that very little seems to have changed in horological principles in the last 120 years or so. Techniques have improved, and tolerances, and modern materials and tools are a help. But there hasn't really been a need for there to be a fundamental advance in horology. The history of technology shows that where there is a clear need, sooner or latter innovation meets that need. Might a clockwork computer be a way of advancing horology fundamentals for the first time in more than a century?

In the next article I'll consider some of the design issues. I'm looking for horological expertise to help draw up a basic design. In fact, I'm even looking for someone who knows how to make a design for a watch, because I certainly don't! If you are interested, do please contact me, dan@shearer.org.





Saturday 11 August 2018

Radio Waves to Random Number Generator

Random numbers are needed for good cryptography, and good cryptography matters for fundamental human rights reasons. Without it, nothing can be kept private. That is why the EU has built its privacy legislation on human rights. And that is why the random number service at random.org is important, because it suggests (but does not show) how to do this right in a mathematical sense.

And so, in the department of "ancient things found in the attic", here is a clipping from the Adelaide Advertiser in Australia. In 1986 I hadn't the slightest idea how important random numbers were, but they seemed fun at the time. Back then, I just wanted to do better than what a basic IBM PC would produce if you asked it to run a pseudo-random number generator.

Unfortunately no, a random number generator based on mashing together multiple radio stations won't work. Radio waves aren't truly random no matter how many we mash together, and there are mathematical ways to show that. It is an important problem to solve, which takes more maths than I currently have.

Dr Mads Haahr of Dublin has all the right mathematics to assess what is a good source of randomness, and he too looked to the air for his solution, but he chose to use static. "The first version of the random number generator was based on a $10 radio receiver from Radio Shack."

Dr Haahr founded Random.org to produce high-quality random numbers for "holding drawings, lotteries and sweepstakes, to drive online games, for scientific applications and for art and music." The theory behind his work is important for all random numbers. Since the topic of random numbers immediately brings up security, I need to point out that random.org is a single source of failure, and since the source code is not published it is not easily possible to verify Dr Haahr's claims of randomness (it could, for all we know, be a clever fake that slightly weights the random numbers this way or that, to the long-term benefit of whoever did the weighting.)

However - the radio waves did get me $500 at the time without actually doing a thing except writing a letter, and a confusing conversation with a journalist who found the concept very strange indeed...


Thursday 9 August 2018

The Problem of Sharing Secrets under GDPR Article 28 Mandatory Contracts

Automating the GDPR - The Article 28 Condumdrum

This article shows how the GDPR sets up a conflict in trust between companies in particular circumstances, which can only be resolved by using the automation of a cryptographic audit trail.

Under the EU's GDPR law virtually every company is a Controller, and virtually all Controllers use at least one Processor. When a Processor is engaged, the GDPR requires that a contract with very specific contents is signed. The GDPR requires that Controllers and Processors cooperate together in order to deliver data protection, and this cooperation needs to be very carefully managed to maintain the security and other guarantees that the GDPR also requires.

In other words, the GDPR simultaneously requires strong cooperation and strong security between companies who can't be expected to have common goals or to trust each other. This is difficult to resolve.



About Controllers and Processors



If you are familiar with the European Union's GDPR, and the roles of the Controller and Processor, then you will be aware of the need for a formal agreement (usually a contract) between every Processor a Controller uses.

Effectively, every company is at least a Controller of personal data, certainly if there are employees or customers. Most companies use at least one Processor for data under their control, from an IT support company, to online storage providers, to companies who consultant and outsource in many ways. A contract between a Processor and a Controller is very carefully specified in legal terms in the GDPR, but the technology implications are not mentioned. This is all in the GDPR Article 28.

About Sharing Access to Data



Not sharing data, but access to the data - for example, does an employee of the Controller log on to the computer system in the Processor? And if so how? This is the kind of scenario that puts shivers down the spine of security professionals, yet here it is in the GDPR.

Controllers and Processors could be almost any company using almost any system, so sharing the access to the personal data across organisations just wouldn't work. Personal data is stored be stored in a different way in every organisation - at a minimum, in difference choices from the 200-odd major databases on the market for instance, besides all the non-database systems in use, and the policies and habits unique to every company.

But the same is not true for the secret keys used to get access to this personal data. No matter how diverse the storage mechanism for the personal data, the secret keys are going to be one of a few types. Most often passwords, but also multifactor authentication codes, or cryptographic key files, or one of a small list of other means of authentication.

Article 28 says that these passwords or other keys need to be available for sharing between Controllers and Processors at any time. And yet no company is happy handing out passwords to their internal systems to unknown people, and anyway this could easily become a breach of the GDPR and the forthcoming ePrivacy legislation.

Where Computer Science Comes In



When a Controller engages a Processor, there are many circumstances under the GDPR when these secret keys need to be shared between these parties, parties who should not trust each other. Therefore, without respect to what may happen with the personal data, the handling of the keys to the personal data is of crucial importance. The law requires that you give some degree of access, perhaps a lot of access, to a company whom you have never met and have no reason to trust. Computer Science has given us many ways to think about interacting with people we do not trust, so this is a problem that can be solved.

Article 28 strongly implies that a particular kind of cryptographically guaranteed auditing process is needed for the keys required to access data, when taken with the post-trilogue texts for upcoming laws including the ePrivacy Regulation, the EU Cybersecurity Act and the European Communications Code. The Cybersecurity Act and the EU NIS Directive are urgently pressing standards in these areas, as are the EU-level security and privacy bodies ENISA and the EU Data Protection Board. With all this human rights-based legal pressure, what is needed is a computer science view of how to implement what the law calls for. Article 28(3)(c) says "takes all measures required pursuant to Article 32" so Article 32 is a part of the mandatory contract, and Article 32 is about security, which also implies computer science.

To discover exactly what kind of cryptographic solution will work, we need to look at the information flows the GDPR requires.

GDPR Article 28 Information Flow



A close reading of the mandatory instruments (normally contracts, but not necessarily) in GDPR Article 28 shows that the required flow of information between Controllers and Processors is entirely one way, from the Processor to the Controller. The Processor has to make numerous undertakings and promises to the Controller, stated in a legally binding manner.

In addition there is a lot of mandated potential communication from the Processor to the Controller, meaning that in various circumstances, there will be communication from the Controller to the Processor if the Controller wishes. At any time the Controller can demand the Processor produce information to prove that processing is compliant, or to require the Processor to assist the Controller in certain activities. The Controller is bound by the GDPR to be able to prove at all times that processing is compliant whether or not a Processor has been engaged.

Relationship of the Parties to Article 28 Contracts



Basic security practice is that the parties to such information flows should not trust each other; they are independent entities who in many cases will not have any other dealings. In addition, each are under very strict legal requirements of the GDPR and the (imminent) ePrivacy Regulations, and the (imminent) EU Electronic Communications Code.

Article 28(1) says "the controller shall use only processors providing sufficient guarantees". According to the computer science referred to in this article, it is possible to define a minimum value of "sufficient guarantee" under the GDPR, but even without that analysis, the Controller must seek some guarantees from the Processor and they need to be not only good guarantees but sufficient to back up the rest of Article 28.

This means that parties to Article 28 contracts are required to meet a particular standard, but also that the parties should not trust each other to meet this standard or any other good behaviour.

Article 28 is All About Processors



Article 28 is all about the Processor being bound to the Controller, with the Controller saying and doing nothing outside what is already said in the rest of the GDPR text. The only reference to a Controller in Article 28 is that the contract must "set out the obligations and rights of the controller" (Art 28(3)) which appears to mean effectively stating "Yes I acknowledge I am a Controller and I am acting according to the GDPR".

There are just two references in the entire GDPR requiring the Controller taking action with respect to using a Processor. The first is ensuring that there is a contract in place that complies with the GDPR. The second is in Article 32(4), which says "the controller and processor shall take steps to ensure that any natural person acting under the authority of the controller or the processor who has access to personal data does not process them except on instructions from the controller".

Technical Comments



Article 32 emphasises the phrase "state of the art", an English expression that has caused much confusion. The phrase is only ambiguous within the confines of English, and since the GDPR is authoritative in multiple languages we can easily compare with German and French and see that multiple versions all agree with one of the English meanings. Therefore "State of the art" means "the art as it is practised today in general", as practiced by peers and as defined by standards bodies and the like. It does not mean the best, most efficient or most advanced technology in existence. It does not mean the most recent. This article considers technologies mostly developed decades ago and very widely recommended and deployed today, which definitely are "state of the art".

Technical Analysis About Audit Records. A log file (Unix) or an EventLog (Windows) is not a quality audit record; it has often been held to be a sufficient audit record in courts worldwide, but in that context it is about balance of probabilities and taking into account other log entries created on other systems at the same time - basically a detective hunt by an expert witness. That sort of thing is an audit process but not a good one and typically only ever involves one logging party. The GDPR Article 28 contract requires that there shall be at least two parties to the audit trail whose actions will be logged, which has not been the case in any law previously. The new EU security and privacy laws use the words "appropriate", "should" and "state of the art" so much that I think it is non-controversial that the audit standard required is much higher. There needs to be a cryptographically guaranteed, non-repudiable audit trail for activities where none of the actors involved (including auditors) need to trust each other, and no special expertise or context is required to interpret the record.

Technical Analysis About Keys A key of some sort is always required to get access to personal data, be it a password, passphrases, physical door pinpad code, two factor authentication or whatever else guards the access to the systems with personal data on it. The Article 28 mandated contract specifies that under many circumstances a Controller and a Processor release keys to each other and therefore to natural persons in the employ of each other. By auditing the use of the keys, we are auditing the access to personal data. In order to remain in compliance with Article 32, we can change passwords/keys at any time, reset the list of authorised persons and therefore also resetting the audit trail. A cryptographically secured audit facility can detect the first time that someone accesses a key.

Technical Analysis About the ePrivacy Regulation I have tracked down the different versions presented for Trilogue, which has now finished. ePrivacy following Trilogue appears to include EU Parliament LIBE Committee amendments from October 2017, including Article 26(a) “In order to safeguard the security and integrity of networks and services, the use of end-to-end encryption should be promoted and, where necessary, be mandatory. Member States should not impose... backdoors". If we are having an audit facility for keys to personal data then it should be end-to-end. Like all end-to-end solutions it will upset government spy agencies or any other party that might want to falsify the record through government-imposed backdoors, because such backdoors cannot work according to mathematics.

Technical Analysis About the EU Code of Communications The Code is broader than ePrivacy (which, it can be argued, is limited by its lex specialis relationship to GDPR.) The Code says: "In order to safeguard security of networks and services, and without prejudice to the Member States' powers to ensure the protection of their essential security interests and public security, and to permit the investigation, detection and prosecution of criminal offences, the use of encryption for example, end-to end where appropriate should be promoted and, where necessary, encryption should be mandatory in accordance with the principles of security and privacy by default and design." We know from Snowden and others that the "without prejudice" phrase is just being polite, because there is no technical means to implement "no backdoors end-to-end crypto" and also not make government spy agencies upset.


Minimum Audit Records Required by Article 28

Detail of Required Audit Records, with their basis in law:

  1. Audit records that list of all natural persons who have access to keys to the personal data, and the changes to that list over time:
    • Article 28(2) "shall not engage another processor", so everyone can see whether or not an unexpected person was authorised for access to keys
    • Article 32(4) "any natural person acting under the authority of the controller or the processor who has access to personal data", so we need an audit log of who *can* have access to keys
    • Article 32(4) "any natural person acting under the authority of the controller or the processor ...  does not process them except on instructions", so we need an audit log of who actually *did* access the keys at least once.


  2. Audit records for who has accessed the audit records above:

    • Article 28(3) "obligations and rights of the controller", shows the controller is watching the processor


These audit records can be technically implement regardless of what IT systems the Controller and the Processor have, because they are only about dealing with the keys. Whoever has the keys has the personal data, and the keys themselves are protected by the GDPR in any case. These audit records are about storing passwords (or other access means.)

Computer Science doesn't seem to allow any way of meeting Article 28 "sufficient guarantee" without a zero-trust encrypted audit model, which these types of audit records enable.

Conclusions



Conclusion 1:
the above minimum audit records are required to fulfill an Article 28 contract between Processor and Controller
Conclusion 2:
if implemented, these records rises to an Article 28(1) "sufficient guarantee" of a Processor being acceptable and therefore the contract being acceptable
Conclusion 3:
there does not seem to be any alternative way of achieving a "sufficient guarantee".
Conclusion 4:
The GDPR requires cryptographic audit facilities to exist and therefore, there is a market for companies to provide these facilities.