1 SENTINELS Program Report 2009 Technology Foundation STW July 1, 2009 Revised: October 29, SENTINELS is financed by STW, NWO, the Ministry of Economic Affairs and ICT Regie
2 2 Sentinels Program Report 2009 Revision October 29, 2009: A technical correction regarding the actualisation of the tariffs for staffing cost of the granted Call 3 projects to the level of the STW OTP tariffs of July Wouter Segeth Technologiestichting STW Van Vollenhovenlaan JP Utrecht Phone +31 (0) Fax +31 (0)
3 Sentinels Program Report Contents Preface 5 Introduction 7 1. Sentinels program overview Call Call Call Sentinels revised budget plan Sentinels project reports 15 Project 06677: JASON 15 Project 06682: ProBiTe 19 Project 06684: DeWorm 28 Project 06687: PINPAS JC 33 Project 07628: VISPER 39 Project 07635: VRIEND 46 Project 07639: PEARL 50
4 4 Sentinels Program Report 2009
5 Sentinels Program Report Preface Dear all, In front of you lies the Sentinels Program Report This report is a combination of the annual reporting and outlook reports we published in the past. By combining them we hope to present a more comprehensive picture of the Sentinels Program. The ambition of Sentinels, is the creation of a comprehensive framework for secure systems engineering. Given the fact that security impinges on every aspect of system design, the realization of this ambition is a real challenge. Sentinels has now come into its final phase with the third and last funding round of projects. Most important of this funding round is the additional funding made available by ICTRegie. This allowed us to change the funding scheme towards industry. The industrial participation in the first two Sentinels rounds is low and raised concerns. The new funding structure has had its impact the industrial participation has grown dramatically. This year 2009, the third and final round of the Sentinels program has resulted in the start of 6 new projects. In 2004, the first round was started with 6 new projects. Two years later, the second round was started with 5 new projects. I see it as a great success of Sentinels that it has succeeded in setting up 17 new projects all focusing on the realisation of the Sentinels ambition. The sentinels research crew is well in place, almost all active Dutch researchers in the field, both from university and industry, are involved in the program. Sentinels goes full steam ahead now. I m convinced that in the years to come, the results of these intense research efforts will result in the fulfilment of the Sentinels ambition. Prof. Dr. Willem Jonker Chairman Sentinels
6 6 Sentinels Program Report 2009
7 Sentinels Program Report Introduction In the years 2002 and 2003 the Sentinels research program was written. This program aims to improve ICT, networks and information systems security, including PCs, corporate and home networks, hand held devices, smart cards, and wireless networks. It targets the technical aspects of security through scientific research in close collaboration between academia and industry. After quite some activity to obtain funding for this program, it started in February In 2004 the main Sentinels activity was the selection of the first round of research projects. All of these projects have started in 2005, and for all a user committee has been formed. In 2006, the second call was announced. One year later, all projects of this call have started. In 2008, the third and final round of Sentinels was announced. In June 2009, the selection was made. The 5 selected projects will start soon. More information about the Sentinels research program can be found on the Sentinels website This Sentinel program report gives a status report of the Sentinels program over is its full period, from its start in 2004 till its expected finish on June 31, The report includes: 1. an overview of the Sentinels program, i.e. call 1, 2 and 3, 2. a budget plan for the whole program period, 3. a status report of the running projects.
8 8 Sentinels Program Report 2009
9 Sentinels Program Report Sentinels program overview 1.1 Call 1 SENTINELS Call 1 Projectnummer TOTAAL Titel JASON IPID Secure Coop. ProBiTe DeWorm PINPAS JC hoofdaanvrager Poll Wieringa Cramer Veldhuis Bos de Vink deelnemende bedrijven en instanties Chess TNO Philips Rabo Philips Res TNO TNO STMicroE Giesecke Bijdrage SENTINELS totaal personeelskosten materieel krediet buitenlandse reizen investeringen totaal universitaire projectkosten Bijdrage bedrijven en instanties eigen personeel materiele steun totaal bedrijfsbijdrage Overzicht projectkosten: totaal projectkosten bijdrage SENTINELS bedrijfsbijdrage bijdrage SENTINELS in % 81% 81% 83% 60% 76% 77% 76% bedrijfsbijdrage in % 19% 19% 17% 40% 24% 23% 24% benogdigde bedrijfsbijdrage in % 19% 18% 17% 22% 25% 20% 15% voldoet aan staffel ja ja ja ja nee ja ja In 2004, the first call of the Sentinels program has resulted in six granted projects. These projects will finish in the time frame The total budget for this call is 2,9 M. The user contribution is 700 k, about 24% of the total budget.
10 10 Sentinels Program Report Call 2 SENTINELS Call 2 Projectnummer TOTAAL titel S-Mobile VISPER SEDAN VRIEND PEARL Hoofdaanvrager Crispo Hartel v Tilborg Wieringa Mauw deelnemende bedrijven en instanties Philips Atos Origin Philips AkzoNobel TNO ICT TNO ICT B/CICT DSM Philips Fox-IT Hoffmann Getr.-Pink Philips Int. BIZZdesign Corus Bijdrage SENTINELS totaal personeelskosten materieel krediet buitenlandse reizen Investeringen totaal universitaire projectkosten Bijdrage bedrijven en instanties eigen personeel materiele steun totaal bedrijfsbijdrage Overzicht projectkosten: totaal projectkosten bijdrage SENTINELS Bedrijfsbijdrage bijdrage SENTINELS in % 84% 81% 88% 79% 85% 83% bedrijfsbijdrage in % 16% 19% 12% 21% 15% 17% benogdigde bedrijfsbijdrage in % 15% 19% 12% 18% 15% 15% voldoet aan staffel ja ja ja ja ja ja In 2006, the second call of the Sentinels program has resulted in five granted projects. In June 2009, the continuation requests of all five projects were approved. The total budget for this call is 2,7 M. The user contribution is 446 k, about 17% of the total budget.
11 Sentinels Program Report Call 3 SENTINELS Call 3 projectnummer TOTAAL titel Secure Metering CREST Mobile IDM Kindred Spirits Revocable Privacy hoofdaanvrager v Eekelen Skoric Etalle Lagendijk Hoepman RU UT CWI deelnemende bedrijven en instanties RDW Irdeto TNO TNO-ICT TNO Alliander Civolution Telin Philips ICTU Ericsson Irdeto De Waag PAIQ BPP BL Bijdrage SENTINELS personeelskosten materieel krediet buitenlandse reizen investeringen subsidie aan deelnemende bedrijven totaal universitaire projectkosten Bijdrage bedrijven en instanties eigen personeel materiële steun bruto bedrijfsbijdrage bedrijfsbijdrage minus subsidie Overzicht projectkosten: totaal projectkosten bijdrage SENTINELS bedrijfsbijdrage bijdrage SENTINELS in % 71% 72% 61% 66% 72% 68% bedrijfsbijdrage in % 29% 28% 39% 34% 28% 32% benodigde bedrijfsbijdrage in % 28% 28% 28% 28% 28% 28% voldoet aan staffel ja ja ja ja ja ja This third (and final) call is a combined call of the Sentinels program and the ICT Innovation Platform (IIP) Veilig Verbonden and has been made possible thanks to the support of ICTRegie. On May 8, 2008, the third call of the Sentinels program was published. In reaction, 19 pre-proposal were submitted, of which 13 were selected to be worked out. On Jun 29, 2009, the Sentinels Program Committee ranked the proposals and advised the Steering Group to grant the five topranked projects. This advice was then overtaken by the Steering Group. The total budget for this call is 3,74 M. The user contribution is 1,25 M, about 33% of the total budget. In the preparation of this call, much effort was given to get more user participation. To increase the participation of the industry in Sentinels, for the first time we allocated a small part of the budget for directly funding the industrial participation. This approach, made possible by ICTRegie, has shown to be very successful, it has resulted in a company matching of 33 % in call 3 versus 17% in call 2.
12 12 Sentinels Program Report 2009
13 Sentinels Program Report Sentinels revised budget plan The Sentinels program budget was initially 7,5 M, with a 2,5 M contribution from the Ministry of Economic Affairs/SenterNovem, a 2,5 M contribution from NWO and a 2,5 M contribution from STW. In 2008, ICTRegie decided to support the Sentinels program with an extra 845 k, to enable the intertwining of Sentinels Call 3 with the first call of the ICTRegie program Veilig Verbonden. Sentinels Program Budget Plan 2008 Current plan k k STW NWO SenterNovem ICTRegie Total In this report, a revised spending plan is presented. In the plan 2008, the reserved budgets for knowledge transfer and office costs were 1 M each. In the current plan, we halved these budgets, because we think that is more realistic. Based on what has been spent on this subject so far, we estimate that for the whole Sentinels period a budget of 761 k for knowledge transfer and 500 k for office cost will suffice. One could even argue that the cooperation with Veilig Verbonden will give some more efficiency in knowledge transfer. Also, we made a close estimate of the costs for Sentinels Assignments Plan 2008 Currrent plan k k Call Call Call Knowledge transfer Office (STW) Total call 1 and 2. This close estimate was reached simply by adding the budgets reserved for the projects from call 1 and 2. Conclusion is that 185k was uncommitted in call 1 and 2. This budget is added to the research budget of call 3 as well. The Sentinels program has succeeded in Sentinels meeting the overall matching by Matching Contributions Plan 2008 industry condition of 25%. To compensate for the low matching contribution of call 2, the matching requirement for call 3 was set to a high 29% for every submitted project. To increase the participation of the industry in Sentinels, a significant part of the ICTRegie contribution to call 3 was assigned for direct industry support. This approach has shown to be very successful, it has resulted in a company matching of 33% in call 3 versus 17% in call 2. Current plan k % k % Industry Call % % Call % % Call % % University p.m. p.m. Total % %
14 14 Sentinels Program Report 2009 To summarise, the Sentinels subsidiary budget for call 3 consists of: 1) the Sentinels budget originally reserved for a VICI-position (845 k ). In 2008 this was re-allocated to the third call for projects, 2) the ICTRegie contribution to the third call (845 k ), 3) the budgets that fall free from knowledge transfer and program office (614 k ), 4) the uncommitted budgets from the calls 1 and 2. Call 3 budget assignments Plan 2008 Currrent plan k k University Research Sentinels subsidy Company Research Sentinels subsidy Company contribution Total A small number of the contributing companies are public knowledge Institutes, like TNO and RDW. The contributions of these companies to the program are counted for as matching, because it significantly boosts the application of Sentinels research. To conclude with, the table below shows the revised payment scheme for the public financers of the Sentinels program for the payment of their Sentinels contribution to the Sentinels program office STW: Payment scheme Public contributions ev July 2014 Total k k k k k k k STW budget reservation NWO SenterNovem ICTRegie Total The specific conditions for these payments will be mutually agreed between the financers and STW.
15 Sentinels Program Report Sentinels project reports Project 06677: JASON The JASON project aims to build a secure system architecture and corresponding programming paradigm for ambient applications that involve a large number of embedded devices. Point of departure is a strict separation of concerns: the programmer only has to specify the security and remote management requirements and then concentrates on implementing the actual functionality of the application. The programming platform and supporting architecture cover a large number of security properties: confidentiality, integrity, authenticity, privacy, logging, transaction support. In the course of the project, the scope of the research has broadened to work on the integration of the JASON approach with Service-Oriented Architecture (SOA), simplifying the job of taking care of the security in a SOA setting. 1 Administrative details project number: 6677 title of the project: JASON, A Generic Architecture for Secure Remote Management name project leader: dr.ir. Erik Poll website: names and fte's of personnel on the project Funded by Sentinels: Richard Brinkman, post-doc, RU, 1 fte, since Łukasz Chmielewski, AIO, RU, 1 fte, since Funded by other sources: dr. Jaap-henk Hoepman, RU. dr.ir. Erik Poll, RU. dr.ir. Bert Bos, Chess IT. User Committee Ben Elsinga, Cap Gemini. Bert Bos, Chess IT. Jan Brands, NXP. The third and fourth user committee meeting were held on January 22 and September 3, Research report for the previous year JASON, the Javacard As Secure Objects Networks platform, was originally designed for smartcards. JASON realizes the secure object store paradigm where objects (that are written in Java) are stored on devices and back office systems. The JASON platform is a middleware layer which securely interconnects an arbitrary number of smartcards, embedded devices, terminals and back office systems over the Internet. It is important to mention that recently embedded devices has been increasingly equipped with SOA, and therefore, JASON should be SOA-aware. Service Oriented Architecture (SOA) is the increasing popular architecture for designing and utilization of business processes allowing for easy collaboration and distribution over networks. The research in 2008 has concentrated on investigating how the JASON concept can fit within SOA, coming up with a concrete proposal to express JASON security contracts as annotations in source code, and developing an approach to use the Java sandboxing mechanism as a basis for achieving secure compartementalisation, as explained in more detail below. Overall goal here is to simplify the
16 16 Sentinels Program Report 2009 task of writing a secure application, while being standards compliant. Implementation work of JASON architecture and the JASON compiler has also started. In the final design of the JASON architecture, JASON is plugged into SAO. The whole JASON system is a SAO security module and therefore the SAO architecture is minimally modified. To specify the JASON security interface, we have decided that the most flexible way is to let the programmer specify the security requirements directly in the source code of a program, taking advantage of the possibility annotation in standard Java. This way the programmer can precisely specify the security requirements as well as the SOA requirements concerning communication (Web Services annotations). The JASON annotations are taken care of by our JASON compiler -- the second part of the JASON system. The JASON compiler extends the Java compiler in the following way. It translates the JASON annotations and WS annotations to a WSDL file that contains the security requirements expressed in the WS-SecurityPolicy standard. SOA security already involves a daunting number of complex security standards. JASON is not meant as yet another security standard. Instead, JASON annotations provide a much simpler description of security contract between service and client, which the JASON compiler then translates to the more complex SOA security standards. To ensure compartementalisation between JASON services, we exploit the possibility in the Java architecture to have multiple class loaders, one for each service, thus providing different name spaces and ruling out the possibility of unwanted direct interaction between services. Another feature of JASON that has been designed is the support for multiple policies. By decoupling the policy from the executable code, the same code can be run with different policies, allowing easy transition from one policy to another. 3 Utilization report for the previous year The integration of JASON within SOA has produced better understanding of how the complexities of web services security can be controlled. The research also provided insight into ways of leveraging existing capabilities of Java technology, through the support for multiple names spaces and user-definable program annotations. The JASON research continues to strengthen the competences of the Digital Security group at the Radboud University in the area of Java program security. It contributes to and benefits from work to other Java-related work in the group, in particular as Java annotations are also being used in the IST EU FP6 project Mobius, and Java sandboxing technologies are also investigated in the Sentinels PINPAS JC project. Jaap-Henk Hoepman took over as chairman of IFIP Working Group 11.2 (Small Systems Security) and has started an effort to refocus this as a group on Pervasive System Security. In 2008 IFIP WG 11.2 co-sponsored the Workshop on Information Security Theory and Practices (WITSP'2008). Publications: Łukasz Chmielewski and Jaap-Henk Hoepman, "Private Fuzzy Matching". Proceedings of the International Conference on Availability, Reliability, and Security (ARES'2008), Polytechnic University of Catalonia, Barcelona, Spain, Łukasz Chmielweski, Richard Brinkman, Jaap-Henk Hoepman and Bert Bos, "Using JASON to secure SOA". Proceedings of the first International Workshop on Middleware Security (MidSec 2008), Leuven, Belgium, Additional presentations: Richard Brinkman, "SOA and security", Capita Selecta course and Software Security course.
17 Sentinels Program Report Łukasz Chmielewski, Richard Brinkman, Jaap-Henk Hoepman and Bert Bos, "Using JASON to Secure SOA", MidSec 2008, Leuven. The following academic papers are finished in draft form and are about to be submitted to a conference: Łukasz Chmielewski and Jaap-Henk Hoepman, "Client-Server Password Recovery". Improved understanding of how security aspects can be more effectively handled in SOA is directly relevant for Chess, as SOA is becoming more important in the market segment that Chess is active in. More in particular, the JASON project is embedded in the business line Machine to Machine (M2M) at Chess. Regular weekly visits of the project postdoc and aio from Nijmegen to Chess in Haarlem have ensured good communication between the project partners. 4 Research plans for the next year The main goal of the work next year is finishing the implementation of the JASON compiler and the JASON framework and releasing this as an open source project. If time permits, we will also look at key management issues in the JASON framework. Another major goal is for Łukasz Chmielewski, the PhD student employed on the project, to complete his PhD thesis. 5 Utilization plans for the next year Work on the proof-of-concept implementation is expected to develop a lot of practical know-how of what is involved in actually implementing the JASON architecture and compiler as well as better insights into the existing SOA security standards that the JASON security aspects have to be mapped to. Java program security will continue to be an important area of expertise for the Digital Security group. We are currently studying the possibilities of a follow-up project. As JASON has become SOAaware and compatible with SOA in the course of the project, a much wider market has opened up for it. Also, we would want to extend the approach of using security annotations, and use them not only for communications between applications but also for tracking data within applications. A follow-up would involve reaching out to a wider audience of potential users. OWASP Netherlands, an active cooperation of Dutch industry interested in web application security in which the Radboud University is already active, would be a useful platform to look for potential industry interest. It will also require understanding how our work relates to other approaches in the field, such as the Security Annotation Framework (SAF) and the Open Service Oriented Architecture collaboration (OSOA). The source code of the JASON platform and the JASON compiler will be released as open source, to allow the creation of a user community. We plan to organise a workshop at the end of this project in an effort to promote JASON and interest potential users. Knowledge of the JASON programme is used in the Machine to Machine (M2M) business line at Chess, more in particular in new generation payment terminal prototypes. Here the ideas and concepts of the JASON, as well as the more practical knowledge in realising these within existing SOA standards, are of direct importance. 6 Contacts with third parties We have been in contact with the SECDAM (Security: development processes and middleware) group at KU Leuven, following presentation of our work at MidSec'2008, and with the Open XKMS project, about relation of our work with other approaches in the SOA world.
18 18 Sentinels Program Report Expenses for the previous year Postdoc Richard Brinkman and PhD student Łukasz Chmielewski have been paid from the project. Additional expenses are travel within the Netherlands, mainly for frequent trips to Chess in Haarlem, costs to participate in international conferences (ARES and MidSec), and the purchase of a project laptop. 8 Expenses for the next year Type specification amount ( ) Personnel R. Brinkman 26,000 Ł. Chmielewski 36,250 Material costs travel NL 2000 JASON workshop 1000 International travels conference visits 5000 Total 69,250 9 Time line and events January 22: third user committee meeting. - March 4-7, International Conference on Availability, Reliability, and Security (ARES'2008), attended by Łukasz Chmielewski. - September 3: fourth user committee meeting. - December 2: 1st International Workshop on Middleware Security (MidSec 2008), Leuven, Belgium, attended by Richard Brinkman and Łukasz Chmielewski February 3, 2009: fifth user committee meeting. - May 15: end of contract of Richard Brinkman. - October 31: end of contract of Łukasz Chmielewski. - second half 2009: JASON workshop. 10 Press coverage None
19 Sentinels Program Report Project 06682: ProBiTe ProBiTe concerns the integration of biometric recognition in security systems. A considerable research effort has been spent on the individual topics of biometric recognition and security, but their combination has lead to new research questions. In particular, ProBiTe focusses on the problems of combining biometric recognition and template protection. Storing biometric templates in a database introduces security and privacy risks, which increase if the database is part of a network. A solution is to apply templateprotection techniques, which make it impossible to recover the biometric data from the templates. The project s goals are (a) to solve the problems of combining biomet- ric identification and template protection and (b) to validate the solutions in a homenetwork demonstrator, to be developed at Philips Research. Fingerprint recognition will be used to identify the user and to control the access to content and devices. Tem- plate protection will be used to protect biometric data. 1.1 Administrative details project number: title of the project: ProBiTe (Protection of Biometric Templates) name project leader: Raymond Veldhuis website: under construction names and FTEs of personnel on the project Funded by Sentinels: Haiyun Xu, PhD student, UT-SAS, 1.0 FTE, since Chen Chun, PhD student, UT-SAS, 1.0 FTE, since Funded by other sources: Tom Kevenaar, Researcher, Philips Research, 0.5 FTE, from until Ton Akkermans, Researcher, Philips Research, 0.5 FTE, from names and affiliations of members of the user committee: Ir. A.H.M. Akkermans, Philips Research, since Dr. ir. T. Kevenaar, priv-id, since Mr. L.A.M. Strous, De Nederlandsche Bank NV, since Dr. ir. B. Schoenmakers, TU/e, since Mr. N. Onland, Dartagnan, since Mr. P. Welti, SAGEM Défense Sécurité, from until dates of the user committee meetings: , UT 1.2 Research report for the previous year Introduction Figure 1.1 shows a biometric template protection scheme. Two biometric measurements, in this case fingerprints, are compared. The top and bottom system both capture the biometric data, extract discriminative features (feature extraction), extract bits from those
20 20 Sentinels Program Report 2009 features (bit extraction) and protect the bits (bit protection) such that the final bit stream is insensitive to occasional bit errors due to variability of the biometric features and can be hashed. One of the hashed bit streams can be stored securely in a database. Features can be compared directly after feature extraction, which is equivalent to stan- dard biometric verification. They can also be compared after bit extraction. This is called binary classification. Finally, they can be compared after protection. The binary classifier is often a Hamming-distance classifier. It accepts the inputs as coming from the same biometric source if the Hamming distance is below a predefined threshold. Comparison after protection is not based on a distance. Only identical strings are accepted. In order to deal with variability of the data, an error correction mechanism is built in the bit protection module. The project is divided into 3 work packages. The work package Template Protection is targeted at developing and optimizing template-protection schemes that enhance security and do not degrade the performance of the biometric recognition. Template protection schemes will be developed and improved such that a maximum number of secret bits, guaranteeing the highest secrecy, are extracted from biometric features while retaining robustness against system noise and intra-class variability. In the course of the project, it has been decided to focus this part of the research on the bit extraction module in Figure 1.1, as viable solutions already exist for the bit protection module. The goal is to extract a large number of discriminative bits from the biometric features. Biometric template protection requires fixed-length feature vectors with known statistics. Therefore, two problems are addressed in the work package Biometric Identification. First, this work package investigates the extraction of robust new types of fixed-length feature vectors with good discrimination properties. Fingerprint recognition is often based on variable-length feature vectors, describing characteristic points called minutiae. The work package investigates methods to encode minutiae sets in fixed-length feature vectors that can be used as a basis for template protection. The new feature vectors may also be based on other characteristics, such as (multi-resolution) shape and (transformations of) gray-scale information. The second topic of the work package Biometric Identification is to address the problem of estimating the relevant statistics given a limited number of training examples. Two classes of solutions to this problem can be identified. The first is to develop classifiers that are less sensitive to this problem. The second is to optimize the transform prior to classification. This work package focusses on the module feature extraction in Figure 1.1. Figure 1.1: Template protection scheme. The results of the work packages Template Protection and Biometric Identification will be
21 Sentinels Program Report validated in a demonstrator, which is developed in the work package Demon- strator. This demonstrator which will be realized at Philips Research Work package Template Protection This work package focusses on extracting, preferably, more than 1 bit per biometric feature. This is done by quantizing each feature into a number of intervals greater than 2 and subsequently coding it with a binary string of length greater than 1. A feature of a genuine user will, with a probability close to 1, be quantized into one specific interval, the genuine interval, which contains the expected value of the feature. For another user this feature will be quantized into an arbitrary interval. Two probabilities are associated to the genuine interval: The probability p d,i that a feature i of a genuine user lies in this interval. This probability, called detection rate must be close to 1, in order to avoid false rejects. The overall false-reject rate (FRR) β of the system is given by M β = 1 p d,i, i=1 with M the number of biometric features. The probability p d,i depends on the location of the quantization intervals and the probability density functions of the features, given that the user is genuine. The probability α i that a feature i of an arbitrary user will be quantized into this interval. This probability must be close to 0, in order to avoid false accepts. The overall false-acceptance rate (FAR) α of the system is given by M α = α i. i=1 The probability α i depends on the location of the quantization intervals and the probability density functions of the features, given that the user is arbitrary. The best secrecy of the protected template is achieved if each quantization interval of a feature i has the same probability α i. Under this condition the relation between the total number of bits N and the overall false-accept rate α of the system is given by α = 2 N [1, 2]. Ideally, a user is only accepted if all extracted bits are correct. Due to user variations and modeling errors, this is never the case. Therefore, an error-correcting code is part of the bit-protection module in Figure 1.1 that can correct a specified maximum number t of errors. As a result, this system operates at a false-acceptance rate α (t ) > 2 N. The false-rejection rate at this point of operation is denoted by β (t ). In the annual report results were reported obtained with two variants of a new bit allocation principle called DROBA (Detection Rate Optimized Bit Allocation) that assigns a variable number of fixed or variable quantization intervals to each feature, such that the overall false-reject rate β (0) is minimal, for a given total number of bits. This method outperforms the bit extraction schemes that have been investigated earlier . A conference paper describing this new method has been published in 2008 . A jour- nal paper has been submitted. The main drawback of DROBA is that it only minimizes the false-rejection rate β (0) at a false-acceptance rate of α (0) = 2 N, which is not the actual point of operation of the template protection system, which is set to correct a number of t errors. However, it has been found that template protection with DROBA also works well at other points of operation, characterized by a maximum number of corrected errors t > 0. As this actual point of operation depends on the application, it is impossible to determine a bit allocation method that would be optimal at this point, i.e, that would minimize β (t ) for a given t. Even if this point were known, this would be prohibitively