Play it safe with serialization
When implementing a serialization, the question comes up how to generate the serial numbers. This apparently trivial question turns out to be extremely complex on careful examination.
Serial codes are considered secure if they cannot easily imitated by counterfeiters and if they cannot get hold of lists of valid serial codes. This means that there must not be a systematic that can be recognized by guessing, for example. If 000123 is followed by 000124, it can be quickly guessed that the next following serial number should be 000125.
Furthermore, it must be ensured that the serial numbers cannot be stolen. This means that all process steps, such as the USB stick used in the production, unencrypted e-mail or the data server, whose access is not sufficiently secured, are ruled out.
Using these criteria, suitable methods for generating serial numbers can now be checked for their protective effect. First of all, deterministic and non-deterministic methods are distinguished from each other:
All procedures that are in no way attributable to an ordered system are called non-deterministic. This includes, for example, gambling, dice or card drawing.
Chance is by definition non-deterministic, otherwise it would not be random. A random number is always only as unpredictable as the amount of possible combinations. With the specifications (alphanumeric and 20 digits) a large amount of random values can be generated theoretically.
However, the first difficulty with randomized procedures lies elsewhere: in the data handling of random values. It is necessary that the random value remains unique in the database system at least over the lifetime of the product. When generating random serial numbers, it must therefore always be checked simultaneously whether chance has not already produced the same combination of values in the past. It is in the nature of things that this process becomes more and more computationally intensive; the more random numbers already exist.
On the other hand: random values do not allow any conclusion to the initial data (thus to the continuous series). Without access to the management software for serial numbers, it is therefore impossible to assign a random value to a specific product. In case of a product recall, all random values would have to be selected from large lists and compared with the numerical values.
Probably the simplest algorithmic procedure: A certain number range is defined and the values are incremented consecutively. With each new packaging unit the counter is incremented according to a certain system. The problem here is that if you only know two numbers, you can most likely predict the third number.
Strictly speaking, this simple, consecutive numbering was already algorithmically expressed: e.g. [x+1] if the value increases consecutively by 1. But since this is somewhat obvious, additional concealment is often used: e.g. by converting letters into numerical values, swapping sequences of numbers [1, 3, 2, 5, 4, 6, 9] or initial values, like the date. At the end you get a sequence of numbers ("code"), which looks very random at first sight.
This deterministic method is already robust. In comparison to random values, it has the advantage that the algorithm can always be used to infer the underlying initial value. In addition, anyone who knows the algorithm can predict the next numbers with certainty. Duplicates in the system can be excluded if used correctly.
However, all purely algorithmic procedures remain critical in terms of security. No matter how creative the algorithm is: the algorithm alone is the security. If it is decrypted or becomes public - in the wrong hands, the protection is void. Since ultimately everything based on the algorithm is "real" in some way, the result would be pure chaos and no one would be able to distinguish which codes are real and which are fake - even worse, it might go completely unnoticed for years.
Cryptography closes this gap. The protection is no longer in the algorithm itself, but in the cryptographic key. The cryptographic key opens the view into the data and shows a meaningful number in the seemingly random letter-number combinations. Since serial numbers only have to be calculated in this way and not stored in a database, the system also remains immune to data thieves. The advantage is that it remains possible to map the codes backwards, i.e. to decrypt them. Thus, a clear proof of authenticity can be provided at any time.
For a final evaluation of the presented methods for the generation of "secure" serial numbers, the main focus is on risk assessment. Random numbers can hardly be seriously considered with regard to process risks. They would be forgery-proof, but completely impracticable in handling. In algorithmic processes without cryptography the risk of decoding remains.
Therefore, exactly these points were taken as a basis for the development of SecIdent. On the one hand, it is important to ensure a 1:1 assignment of codes to serial numbers. On the other hand, the encryption procedure must remain secure against (unnoticed) compromise.
We can guarantee this because the SecIdent system generates the codes cryptographically. With this procedure, the algorithm can be disclosed without any problems, without the code being able to be converted back into a serial number.
It is the combination of highly secure encryption mechanisms and sophisticated system architecture that SecIdent-System recommends for use in the context of Pharma Serialization.