[Cryptography] How programming language design can help us write secure crypto code

[Brian Gladman]

I have been lurking on this thread for some time but have been
reluctant to join in as I know from previous experience that any debate
on the extent to which programming languages can impact on the integrity
of the systems will very often raise a great deal more heat than light.

In my work in defence in the period from 1961 through to 1998, I was
lucky enough to be at the centre of systems engineering research and
development in two fields, both of which should have needed high
integrity systems engineering approaches.

The first of these was safety critical systems in areas such as aircraft
and missile flight control, and in weapon systems fusing, arming and
release.  The second was in secure information systems.

What struck me during this time was that while we saw a strong degree of
commonality in what these two domains needed in terms of systems
engineering, in reality the approaches adopted within the two domains
could hardly have been more different.

In the safety critical systems domain there was an enormous focus on
systems engineering at every stage in development and a great deal of
rigour was involved in developing requirements and in translating these
into forms from which designs could be developed and then measured for
conformance.  There was an equally rigorous approach to the
documentation of the design itself, and to the development and
management of the interfaces and the design specifications for the
component parts and in the development, documentation and operation of
the systems tests and systems monitoring both during development and in
eventual operation.

And then within the Ministry of Defence there were very senior managment
Boards that had the responsibility for giving the final approval for the
operational deployment of all aircraft and weapons systems (the Ordnance
Board has a history going back to the Tudors
https://en.wikipedia.org/wiki/Board_of_Ordnance).

In the security critical systems domain, however, there was none of this
rigour at a systems engineering level with the result that systems were
'put together' rather than being designed. And there was no senior
management Board that had resonsibility for approving the operational
deployment of security critical systems.  Here each bit of the defence
estate did its own thing.

When it came to their attitude to research and development (R&D), the
reaction of the companies and organisations in these two domains was as
different as their approach to systems engineering.

The Royal Radar Establishment (where I worked) had some success in the
70s with a programming language callled Coral
(https://en.wikipedia.org/wiki/Coral_66) but rather than continuing with
this in the 1980s we decided to participate in the US DoD effort to
develop Ada.  And here once more the reaction of the UK companies and
organisations involved in safety and security could hardly have been
more different. Those involved in safety volunteered to get invoved in
the language design and development process with very little
encouragement from us. But those involved in information security showed
an almost complete disinterest despite a considerable effort on our part
to get them involved.

The reaction was also the same in another initiative we took in
developing a processor architecture
(https://en.wikipedia.org/wiki/VIPER_microprocessor) for use in high
integrity systems.  Once more we got a lot of support from the companies
and organisations involved in safety critical systems but at best
bemused disterest from those involved in secure systems (GCHQ and NSA
were notable exceptions here). [1]

I am sorry for all this background, but I think it may help in making my
main point - that there is a big paradox in the reactions of the safety
and security critical communities to the role of programming language
choice in building high integrity systems.

Although within the safety critical systems community there has been a
significant adoption of Ada and SPARK -- see
https://en.wikipedia.org/wiki/SPARK_(programming_language) -- the
paradox here is that, when set within the context of an overall systems
engineering approach, the language choice is really not critical.
Although it would certainly have taken longer and cost more, these
systems could have been programmed in hand coded binary and still
achieved the high integrity required of them.

But those involved in building security critical systems in the 1980s
and 90s were mostly involved in putting systems togther from the bottom
up using any C compiler that came with the hardware (that they had often
chosen before knowing what the system had to do). And, as I know from my
efforts at the time, any suggestion that they needed a more systematic
approach to system design - or that C might not be the most appropriate
language choice - was very often met with derision.

The point is that within the safety critical domain the focus on systems
engineering and the understanding of the role of language choice within
this process are mutually reinforcing in the drive towards higher
integrity.

In contast, although we talk about information systems engineering, my
feeling is that most information systems are still 'put togther' rather
than being engineered. And here the choice of C as the programming
language with its focus on being near the 'metal' acts to encourage a
bottom-up approach to systems construction and acts to weaken any
pressures that might encourage the evolution of a more systematic
approach to systems design.

Here the relative weakness in systems engineering and the almost
universal acceptance of C as the language to use (or the only language
on offer) are mutually reinforcing in a downward direction when it comes
to any drive towards a more systematic apppproach to higher integrity.
As other have said the combination of C with a belief that building
secure information systems is all about writing code is a toxic combination.

My conclusion is that while it is systems engineering that really makes
the difference in achieving high integrity in computer based systems,
the choice of language can have a significant influence on the rate at
which a community evolves an understanding of the need for an organised
approach to the engineering of systems.

And here, while other factors have had a larger impact, the almost
universal adoption of C as the language to be used in building
information systems has in my view played a small but nevertheless
significant part in delaying the evolution of a systems engineering
approach in their overall design.

   Brian Gladman

[1] VIPER ulimately failed in a botched MoD attempt to commercialise it.