In the same period, we exchanged the Pascal 2 compiler by the new Pascal 3 compiler. Pascal was developed by Nicklaus Wirth at the Eidgenosische Technische Hochschule Zürich (ETZ). The compiler delivered highly optimised code for a CDC 6400. Additional system routines and functions were added by both the computer center of the Universities in Amsterdam (SARA) and us. Around 1983, we tried to convince the Pascal compiler to compile in a couple of stages (using DIANA), a ADA-compiler that was written in Pascal. This required very large compiler tables, ASCII rather than 6-bit bytes. Unfortunately, this project was overtaken by more urgent projects.
The disk capacity was always to small. This despite the exchange in February 1983 of three CDC 844-41 disk units by two CDC 885-disk units, which gave a double capacity. Thus we decided to remove inactive and old files each week from the system by archiving them on magnetic tape. The users could request an archive, delete/clean-up or a reload by using a program that looked at the "INDEX-system". Archived data was guaranteed for two years. The INDEX-system made heavily use of the new Cyber Control Language-features (CCL; 1982).
Cyber Control Language (CCL) was a - in UNIX-language - kind of shell-language. We, at the Physisch Laboratorium TNO, added numerous features to CCL in order to let the system use in an optimal way, both by operational users and the normal users. Additions like "empty" parameters, print-suppressed "security" parameters and substrings were added. Most of these additions were developed in 1980. The CCL-procedures for the Texas Instruments Micro Development Station (MDS) were halved in size, resulting in efficiency gains on the CYBER during expansion, parsing and execution of the CCL-procedures.
User friendly was something else, especially one had to wait for the next night
before the job could be run again. Reason enough to try to obtain the 'public-domain'
(already at that time!) post-mortem dump (PMD) analysis software package developed
by the University of Manchester. As that University just got rid of the lower
Cybers and only had a CYBER 205 supercomputer left, the package support
was transfered to the University of Leicester, a NOS-site. They would provide
us with the magnetic tape with the code, but we had to develop our own changes
to get the package running under the NOS/BE operating
system. That required some changes to the Fortran compiler as well as to the
LOADER and the segmentation loader (SEGLOAD).
Just a couple of weeks after putting the PMD/Leicester Trace Package (LTP) into production, CDC delivered a new level with surprisingly much new loader-code. A new feature that saved a lot of the expensive fixed (non-virtual) memory was "dynamic load" (DLL's!). Especially, major parts of the Fortran library were made completely dynamic. (e.g. the I/O-modules).
Adapting PMD/LTP for another operating system was one thing. One had to figure out problem system calls (another type of system call signalling) and change them. Adapting the package for these new dynamic, highly undocumented features, however, required full insight and understanding of the working of the package itself.
After a lot of work, PMD/LTP was able to recognise the dynamically loaded routines in memory. At that time, PMD/LTP was brought into production again. That had large consequences for most users as we changed the behaviour of the loader in such a way that the use of uninitialised data resulted in an abort of the program. At the end this resulted in a large quality improvement and less 'strange' behaviour of the program during execution.
During the next phase, we expanded the standaard NOS/BE operating system with
additional security code. Operators could not look anymore at the console into
"sensitive" memory areas. A much stricter function separation was introduced
between Operations and Systems programming. Only after entering a password,
the console was released for full functionality. We developed a very small 100B
PP-overlay that was coded completely "relative".
Thus it could be read and executed at any place by another PP program. This
PP overlay program was cataloged (stored) as a system permanent file with by
the system at the moment of cataloging generated lees-,
modify-, append- en write passwords that included information from the system
microsecond clock. Every generated password was unique and contained characters
that were not accepted by the normal permanent file routines. Moreover, even
the system programmer, could not obtain the password unless very dirty tricks
were used, which require full access to the operating system and the system
memory. Only one control password, "Os0lem1o", (O-solemio) was left for the
system programmer to remove the system file.
Only one special system PP-program could attach the file with the security overlay, and could trick the system by setting the read permit in het system memory. Then it could load the system unlock overlay code into the display PP (DSD). The overlay code contained a kind of pin code to unlock the secured system. When the PP overlay could not be loaded, the system was locked completely. This security code gave an optimal protection for the operational system.
To test new developed security code requires many tricks. Debugging required an 'open, unlocked system' while on the other hand one wanted to use sensitive jobs. It is very cumbersome to test security in a system that is optimal secured against users and system programmers. The trick we used was to develop and compile the security code. Then, from behind console the binairy "executable" code was read into memory using the (by ourselves extended) O26-console editor, which was another PP-program). At the left screen, the octal memory was displayed, making it easy to look at the security code and change that by patching memory. Then, O26 was used to save the file. That slightly adapted PP-code was brought into the system using EDITLIB(SYSTEM). Then all the required tests could be made, and when the code worked as expected, the original binary code could be added to the system without another recompilation. This saved a lot of time as it took an hour compilation time or more when extensive changes were made to, for instance the console display driver PP DSD.
As an example of security code that was developed for the various PP-programs, one can take the PP program ABS that could dump the absolute memory contents onto paper or a file. The standard code of ABS allowed each user to dump a major part of the system main memory and the user's own occupied memory space. ABS was changed in such a way that the memory contents was reported as zeroes unless:
In 1981, we introduced the Tape Security System (TSS) which was developed by the University of Bologna, Italy. We had to convert the package to the latest NOS/BE release, solving a number of errors, and extended the package with improved logging. It became impossible to read or overwrite tapes of other users, unless the password of the tape (hidden in an extended tape label) was known.
An American contact of us developed quit efficient Data Encryption Standard (DES) utilities in Compass (assembler). We received a deck of punch cards, a couple of weeks before new US export rules stated that export of DES code was illegal. The DES-routines were used by us at that time to encrypt a number of sensitive data.
In the beginning of 1984, additional security measures were taken which included
more stringent password rules to be enforced by system programs.
We changed the INTERCOM (interactive users) password system in such a way, that
an additional password file was created that contained a
"physical record unit" (PRU) of 64 words for each user. The users' PRU contained his
last ten one-way encrypted passwords. This in order to avoid (illegal) re-use of passwords.
The upcoming first PC's were sometimes programmed to do an a-b-c-..a scheme to bypass
the change of passwords. Cleverly, we only moved the ten old password stack when the password
was really used to logon. Otherwise only the new password was cycled. This countermeasure
annoyed many of the smart users! The PRU contained time/date of the last five login's
as well as counters that forced users to change their passwords after 250 uses or three months
giving them a grace number of login's.
In total, over three thousand lines of security code was developed that modified the behaviour of fourty system applications and many PP programs and overlays.
Security measures extended also to physical security. In 1978, we developed a method to "clean" defective disk packages. Using sand grit, we really cleaned disks to comply with NATO security regulations. During the introduction at the world-wide VIM/ECODU users conference in Minneapolis of the new 885-disk units that had head-disk assemblies (HDA's), we signaled to Control Data that the standard maintenance contract required CDC's maintenance engineers to take the HDA (media and heads) with them in case of errors. The security regulations required us to keep the disks unless we could guarantee that all data was "deeply" removed. Based upon our suggestions, Control Data made a world wide change of the standard maintenance contract allowing sites to keep the HDA's. The cost involved was recovered by a small "insurance" increase of the maintenance costs.