Breeder documents, and specifically birth certificates, are a vital link in the identity management chain, and the lack of security in these documents constitutes a very important problem. In this article, Tomasz Golinski deals with the process of developing birth certificates, and describes helpful rules that can be found in the (professional) literature.
According to the definition given by UNICEF, a breeder document is “an identification document issued to support a person’s identity and used to obtain another document or privilege of greater perceived value. The most important breeder document is the birth certificate.”1 Unfortunately, breeder documents are often not designed as security documents. Even when the issuer tries to make them more secure, the fact that the technology of colour reproduction is continuously improving makes it possible to print fraudulent documents with relative ease. Forensic specialists have hardly any difficulty in identifying imitations, but the general public, including employees of state administration offices, find it hard even to distinguish fakes that are prepared using office equipment. To improve the situation, both well‑designed prints and the right education on how to check a document’s authenticity are needed.
Security problem analysis
In this article, designing any type of security document is understood as a development process, embracing not only graphic design, but also determining its form, and choosing and integrating adequate security features. Therefore, the terms ‘designing a document’ and ‘developing a document’ are used interchangeably in this article.
Before discussing the development of the breeder documents, it is good to have a quick look at the basic principles of the security problem solution, of which the security design is a part. The process is well‑presented in Professor Van Renesse’s book on optical document security.2 Figure 1 shows the schematic drawing which illustrates the concept.
In short, the process can be described as follows: first we must be aware of a security problem caused by the threat of for example counterfeiting and forgery. This real or potential threat is a source of damage we would like to avoid. The intention to solve the problem should be the reason for formulating a security policy, strategies and a list of requirements which should be met by the solution. A security programme should be set up to enable us to choose the adequate security measures to be integrated in the design of our security product, such as a breeder document. A very important part of this process is risk analysis, taking into account the probability of threat occurrence, the damage caused by it and costs connected to the implementation of the security policy and measures. One should avoid situations where the costs exceed the financial damage, unless some kind of intangible loss is predicted, such as losing the citizens’ confidence, which would justify such a move. Also, when the threats aren’t likely to happen, one might steer clear from excessive costs of countermeasures. In order to get good results one should repeat the security problem analysis and solution synthesis a number of times.
Parties involved in the process
During the development process at least two parties should be involved: the supplier of the documents and the party who ordered them. When more institutions are involved, the setup can be different. For example, in the case of Polish birth certificates the decision of what the prints should look like lies with the central administration, but documents are issued by civil status offices which are part of the local administration offices. Similarly in many countries, government institutions care about the civil status system as a whole running well, but the actual documents are personalised and issued locally, so citizens can apply for and receive the documents they require quickly. In their book ‘Documents: the developer’s toolkit’ Diana Ombelli and Fons Knopjes show what a typical document gestation process looks like in this situation (see Figure 2).3 The term ‘gestation process’ is broader than ‘development process’, it includes both the creation and implementation of the new document.
As one can see, the process also includes the choice of supplier and the tendering procedure. The implementation and tendering procedure are separate issues and lie beyond the scope of this article. Readers who are interested in more detailed information regarding these stages can refer to literature sources.3‑6
Development process
The development of a particular document can be managed as any other kind of project. The organisations mentioned above should be represented, because each of them brings their own knowledge. With this knowledge a list of requirements can be prepared, which should then be transformed into a proper document design with accompanying specifications. In reality this is not as straightforward as it looks in Figure 2. The process is usually more interactive and starts even before the contract is granted. There are preceding discussions between the commissioning party and the producer‑to‑be. Frequently, the design process cycle shown in Figure 3 must be iterated in order to obtain an acceptable design with characteristics that match the criteria (list of requirements) formulated during the security problem analysis. Sometimes it also results in changing the requirements to make them more realistic. Prototypes of the document are very helpful in the design evaluation stage.
Project development team
“The ultimate aim is to develop the document in an effective and structured way.”3 Ombelli and Knopjes maintain that in order to achieve this, it is best to have a small and professional core project development team consisting of a representative of the commissioning party, a creative designer and a supplier’s product developer. Every team member should possess knowledge in their area of responsibility and cooperate in an open manner with the others. Naturally, the team can be supported by other experts, such as representatives of material suppliers, but their work is crucial for the final success. The list of requirements should be written down, distinguishing ‘must haves’ and ‘should haves’, not all requirements are equally important. Some room must be left for modifications at a later stage, to avoid legal and technical problems at that point. The design team should also try to think from a document users perspective, and take into account what is important for them. The latest high‑tech solutions should be tested before including them in the design, to avoid teething troubles. Security features must be evaluated to decide what their added value is to the document chain. Security features that both address more fraud threats and are easily integrated in the graphic design of the document are preferable.
Issues to consider
There is plenty of information to be gathered during the development process. Most important is the information about the function of the document, its usage and storage including time and environmental conditions, expected lifetime, withdrawal or validity extension, inspection circumstances and methods of application, the holders’ group, and the application and issuance process.3 Obviously, information is needed on the available budget and the results of the threat analysis carried out beforehand. It is important to analyse potential weaknesses in the whole security chain of operations connected to the security document’s lifecycle, including the application for the document, its production, personalisation, issuance, use and authenticity verification.
Interestingly, in Poland (and supposedly also in some other countries) birth certificates do not expire. There-fore, unless the document is in a bad state and has for example become illegible, or there are regulations regarding the age of the certificate used for some particular formalities, it can be used for many years after issuance. It cannot be withdrawn and there is no need to extend its validity.
Types of fraud
In general, these types of document fraud are encountered:
• counterfeiting;
• fraudulent alteration;
• unauthorised personalisation of original blank documents;
• misleading the issuer by submitting false data or stealing somebody else’s identity;
• using fancy documents.3
Depending on the situation, in the case of birth certificates, all these types of document fraud are possible and should be considered during the risk analysis. Misleading the issuer is more related to obtaining false entry into the state register than forging the document itself. The child is then the unwilling and unaware impostor and the person requiring child registration is the forger. An imposter can also use somebody else’s document, because usually there is no link between the birth certificate and the person to whom it has been issued.
Tasks of the development team during the synthesis phase
The development team should concentrate on the following tasks during the synthesis phase of their work:
• choice of document form;
• development of various specific security elements, such as optically variable devices;
• choice of production technologies;
• selection of materials, such as substrates and inks;
• preparing the layout of personalised data, taking into account the possible length of the inscriptions;
• creating a graphic design with integrated security features;
• selection of the personalisation system and technology;
• preparing quality requirements and testing methodology.3
These tasks are interdependent, so they can’t be addressed separately. The final result will be a compromise attempting to satisfy conflicting demands. Sometimes, however, there can be a kind of synergy between different parts of the design: the chosen personalisation technology can for example add unique security features that will complement and enhance the security of features introduced during the document manufacturing process. Some of the security issues can’t be solved solely by the proper document design, and for these it will for example be necessary to introduce proper security procedures or a supporting IT system.
The creative designer is a crucial team member. He or she will have to integrate all the developed elements in the final design. Their main goal should be to translate the selected document concept into a design, effectively combining the required elements with respect to the document’s security and ergonomic use.3 As an experienced security document designer, Joost van Roon, puts it: “Security document design is no longer a matter of simply employing a few guilloches, a numismatic structure or some special rasters.”7 Recently, things have become even more complicated for the creative designers. There is a growing need in design to take into account two additional factors: firstly, the requirements resulting from the development of machine authentication of security documents,8 and secondly, compliance with the principles of human perception science for improved human verification of a document’s authenticity.9
The testing of a document can’t be neglected, because it helps to evaluate the fulfilment of the requirements and will answer questions regarding the future performance of the document. In the case of birth certificates, there are no technical standards which can be followed, so writing a testing methodology requires some creativity, but also common sense. Testing should, among other things, allow checking whether the required functionality has been achieved and whether the security features and the security design as a whole are effective enough to counter the recognised threats. As mentioned before, the validity of a birth certificate is often not limited. Therefore, tests should prove their long‑term durability and may include climatic tests (artificial aging), tests of lightfastness, and resistance to abrasion, chemicals and wear and tear.
Budget considerations
Each solution for a security problem has its financial cost to be covered. While evaluating the budget needed for the introduction of a solution involving security documents, it is important to remember different aspects. They include the costs of:
• the solution development process;
• the production process (materials, labour, machines amortisation, licences, quality control, etc.);
• data acquisition;
• document personalisation and issuance (equipment amortisation, consumables, maintenance, personnel, data acquisition, quality control etc.);
• assuring physical security of production and personalisation;
• secured transport;
• tests;
• implementation (preparing the issuer, informing and training the user groups, supplying verification tools etc.).
In the case of birth certificates, the costs of accompanying ICT systems (for example for civil status register databases) should be taken into account as well.
Usually, the commissioning party does not want to spend too much money, but too small a budget can result in failing to achieve a secure solution fulfilling all the initial requirements. Availability of information on the losses caused by the unsolved security problem should help to put the solution costs in the right perspective. Unfortunately, as the losses are seldom covered by the commissioning party, they are not always open to this kind of argument.
Summary
The security of breeder documents was neglected for a long time. In recent years, the number of travel document fraud attempts based on forged breeder documents has grown substantially. As it is more frequently a case of identity fraud, rather than passport forgery, finding the right solution for this problem has become extremely important. There are no international standards for breeder documents, but that does not mean that there are no rules which can be used for the design of birth certificates. They can be treated like any other security document. Principles of secure document development can be found in the existing literature. State administration institutions ordering breeder documents and their manufacturers should apply the rules. This will enable us “to develop the document in an effective and structured way.” Such an approach is far more likely to be successful than just randomly choosing nice‑looking security features, which aren’t well‑integrated in the graphic design, but do fit the budget.
This article is based on the presentation the author gave at the 26th International Security Printers Conference organised by INTERGRAF in December 2013.
References
1 A passport to protection: A guide to birth registration programming (2013). United Nations Children’s Fund (UNICEF), New York. http://www.unicef.org/protection/files/UNICEF_Birth_Registration_Handbook.pdf. Accessed on 23 April 2015.
2 Van Renesse, R. L. (1998). Optical document security, Artech House, Boston, London.
3 Ombelli D., and Knopjes F. (2008). Documents: the developer’s toolkit, IOM and Via Occidentalis Editora Lda.
4 Hartman M., and Coulter Ch. (2010). Implementing e‑MRTD Part II‑A: Procurement and Implementation. MRTD Report, Vol. 5 No 1, pp. 17‑21.
5 Hartman M., and Coulter Ch. (2010). Implementing e‑MRTD Part II‑B: Procurement and Implementation. MRTD Report, Vol. 5 No 2, pp. 19‑24.
6 Ombelli D., and Knopjes F. (2010). Tenders: How to avoid the risk of litigation. Keesing Journal of Documents & Identity, Vol. 31, pp. 27‑29.
7 Van Roon, J. (2014). Avoiding amorphousness: The ins and outs of intelligent security design. Keesing Journal of Documents & Identity, Vol. 43, pp. 24‑29.
8 Schneider, U. and Seidel, U. (2014). Current aspects in machine authentication of security documents: Unused potential and the need for improvement. Keesing Journal of Documents & Identity, Vol. 43, pp. 3‑12.
9 The Science of Perception Testing. Opinions or perceptions? IBDA News, Vol. 2, September 2011, pp. 2‑4.
10 http://ciec1.org/ListeConventions. Accessed on 23 April 2015.
Tomasz Golinski holds an MSc in Electronic Engineering from Warsaw Technical University and an MBA from the University of Gdansk and the Gdańsk Foundation for Management Development (GFKM). He joined Polish Security Printing Works plc (PWPW) in 1990 and has held several managerial positions, mainly in R&D. He participated in many development projects introducing new solutions, and currently works in the Strategy & Marketing Department.
