The Y2k Problem and Security Technology

Content:

Introduction

A Recent Case

Leap Year Problems

Access Control Systems

Time Registration Systems

Solutions

Copyrights

Introduction

We have known about this for 30 years. Within the field of computing the Y2k problem has been known for a long time. Already back in the 70's, banks and insurance companies were able to establish the fact that the change of year from 1999 to 2000 would cause problems when calculating life insurance policies and long-term mortgages. lt was always necessary to take special measures to account for the millennium change in these calculations. The main cause of the problem was that computer memory was rare and expensive back then, so everyone used two rather than four digits to store years. The consequence was of course that the year 2000 came up as 00 in two-digit calculations, and this gave rise to a number of calculation errors, e.g. division by zero.

However, things get even more complicated. Not only will the change-over as such cause problems, but it is further complicated by the fact that year 2000 is a leap year of a type which only appears every 400 years. A number of different program routines are used to calculate leap years. Since long product life cycles are not exactly the norm in the computer industry, it stands to reason that the short versions of leap year routines prevail. These will correctly calculate leap years in 100-year spans but do not take the special situation arising every 400 years into consideration. Thus, they do not recognise year 2000 as a leap year.

In the meantime the Y2k problem has penetrated from the mainframe scene into the widespread software and hardware of the PC world. The closer you study the millennium problem, the more complex it becomes, and you realise just how many technical areas it touches and how many of these directly influence our daily existence. An area which so far has received too little attention is the field of embedded systems, all the small systems built around micro processors or micro controllers that control heating systems, chemical plants, toasters, washing machines and cruise missiles.

Many of these small hidden computers are old, forgotten, difficult to find and impossible to alter functionally. Luckily, the operation of most of these systems do not directly depend on particular dates nor do they need to calculate dates. However, most of them do contain clock functions and need to calculate time interIs in order to start or stop programmed activities correctly.

Nobody knows how many of these systems exist, in which machines they are embedded or exactly which functions they undertake in these Systems. Furthermore, many embedded systems were developed and manufactured by small companies, many of which no longer exist. In most cases no documentation describing development and programming of these systems exist. When you ask developers who were busy developing embedded systems in the 80s, time after time you receive the reply that nobody could foresee that these systems built around 8-bit CPUs like Z80 or 8032 as they were, would still be in use 20 years later. Thus, the main problem with embedded systems is that it is impossible or at least very difficult to establish which systems may be susceptible to the Y2k problem and how a failure will influence the operation of the systems in which they are embedded.

lt seems realistic to assume that most embedded systems will continue to function, but the fact should not be disregarded that the more complex the functionality of a system, the higher the probability that a micro processor is used to control it. And complex systems tend to fail in complex modes.

A Recent Case

Only thanks to pure coincidence, a Y2k problem was recently discovered in a complex security and alarm installation.

The problem here was the very simple date comparison used in a DCF77 time constant hard coded into a ROM in the system. lf a DCF77 time constant is fed a value of 2000 for the year, the system automatically enters a failure mode from which it cannot recover or even be reset while the 00 remains at the input terrninals of the DCF77.

The precise reason for this is an illegal computer operation which causes the micro processor to generate an error signal (a type of error which in this case was unknown to the rest of the security system). This state requires a manual reset, and the system simply waits for this. Because the manufacturer went bankrupt in 1993 the owners of this system could not hope for a remedy. Their system will simply cease to function by the end of 1999.

Fortunately, only three systems of this type have been installed in Germany, and the three owners have discovered the problem in time to replace them. This is currently happening.

If these problems had been known earlier in certain circles it would have been a trivial matter to intercept the DCF77 signal and replace it with a forged signal indicating that the year was 2000 and the security system would have shut itself down, conveniently allowing access. This is just one example of the possible effects of the millennium change on alarm and security installations whose functionality depend on micro processors.

Leap Year Problems

With regard to the effects of faulty leap year calculations a number of security installations can be expected to fail as a cause of this.

Among the systems that are particularly vulnerable, access control systems and time registration systems should be mentioned. In year 2000, February 29th is a Tuesday, i.e. (hopefully) a normal workday.

Access Control Systems

In case of access control systems two failure modes can be expected.

In the first of these the very existence of February 29th goes unrecognised, and the system simply continues to function but thinks that the date is March 1st. The second failure mode is when the system does recognise February 29th (e.g. because it is connected to a DCF77 time signal) but is unable to reconcile the existence of this particular date with its internal routines for calculating leap years. In this case the system may switch itself into some sort of failure mode and display some sort of 'error'.

The first of these two failure modes can be solved through administrative measures including a subsequent reset of the system date. The second failure mode is more problematic because the 'error' condition may mean that the system refuses access to the protected areas on February 29th, or perhaps that it allows everybody access.

Time Registration Systems

Like access control systems time registration systems are easy victims of Y2k problems.

Thus, it is quite likely that workers showing up for work on February 29th will find that the time they put in was registered as belonging to March 1st, in other words, that a whole day will be missing from their February salary accounts.

Solutions

For those who have not already been coping with the Y2k problems of their organisation for some time now, time is seriously running out.

In the IT sector almost all competent resources have already been completely booked for years. With regard to embedded systems the case is made much more difficult by the fact that it is not just a question of implementing known methods to automatically isolate the problems. The search methods used in the IT sector can only be adapted to cope with embedded systems with difficulty - if at all.

In the short term the only hope for help is contacting the manufacturer of suspect equipment or plant. Only the manufacturer can (or rather, ought to be able to) provide information with regard to the Y2k compliance of his products.

For legal reasons, it is important that both requests for information and the replies be conducted formally and in writing. Any declaration regarding Y2k compliance should be given in a legally binding form. In case of installation of any new equipment the purchaser should demand a written Y2k compliance statement. In case an installation is not Y2k compliant but can be made so through changes, these should be clearly stated together with a declaration stating that the Installation will be Y2k compliant after the suggested changes have been carried out.

In many cases, unfortunately, the only solution is a complete replacement.