Heath Novak
email: novak667@regis.edu

Daniel Likarish
email: dlikaris@regis.edu

Erik Moore
email: emoore@regis.edu

Developing Cyber Competition Infrastructure Using the SCRUM Framework

Keywords: Collegiate Cyber Defense Competition, CCDC, Cybersecurity, Information Assurance Curriculum, Agile, SCRUM, SDLC, Capability Maturity Model Integration, CMMI

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

The Collegiate Cyber Defense Competition (CCDC) [10], developed and organized by the University of Texas, San Antonio has steadily grown to encompass all 50 States in the Union. In 2012, Regis University joined the CCDC family by hosting the Rocky Mountain Collegiate Cyber Defense Competition (RMCCDC). A total of seven schools participated in the event and six out of the seven teams competed for the chance to be invited to the Nationals competition. Victorious student competitors from all hosted CCDC regional competitions are invited to compete for the top prize at the University of San Antonio Nationals. The last report by an official within the University of San Antonio CCDC steering committee stated that all 50 states are onboard to take part in the competition. These schools have a special motivation to be involved because they can gain recognition for their cyber defense curriculum as well as offer a unique opportunity for students to gain hands-on experience assisting in developing the infrastructure for the competition. By competing in the event, students are offered an additional learning opportunity for personal growth and are provided a venue to demonstrate their business and technical skills to potential employers.

The task of developing the information systems infrastructure is not trivial and takes a great deal of coordination and technical savvy. Black is the color identifier for the team in charge of infrastructure development and maintenance for the event. The skills gained and exercised as a member of the Black Team is unique and well-suited for individuals in a general or security-focused information systems engineering role as necessary skills exercised include systems engineering, project management, systems administration, and software development. This paper reviews the project management methodologies as applied to the goals and situation of the Black Team at the Regis-hosted CCDC event and makes general recommendations based on outcomes.

CCDC: The Collegiate Cyber Defense Competition

The CCDC event is typically composed of five primary teams: the competitors (Blue teams), the attackers (Red team), the competition infrastructure engineers (Black team), the Blue team facilitators (White team) and the judges/rules enforcers (Gold team) [10]. The CCDC event typically consists of six Blue teams competing in the event, although the RMCCDC event hosted by Regis University had a seventh non-competing team. Each Blue teams consisted of eight individuals (two graduate and six undergraduate students) tasked with protecting a pre-configured and provided information system infrastructure functionally identical to that of the other teams.

The information system infrastructure consists of flat network architecture, various servers and workstations supporting valid business or mission-critical applications that emulate the internal functions of a real-world organization. Injecting realistic customer, business, and security events into the event enhanced the knowledge gained by the participants to achieve greater real-world value and therefore more benefit later when they enter the workforce.

The scenario touches on current events and includes valid applications that leverage standard Internet protocols and security controls. Further, the scenario includes enough content to keep the competitors busy with deliverables that demand effective communication between team members in order to emphasize the importance of interpersonal communication during periods of critical activity. One key facet of the event is the injection of stress, or "injects," such as providing deadlines for specific business reports and change requirements as written and enforced by the Gold team. These injects are service level agreements (SLAs) that are provided up-front and include specific deadlines for completion, typically within an hour. Injects can also be issued randomly, in order to simulate normal, on-demand business activities. Inject responses allow the Gold Team to assess how the competitors handle normal business activities along with the threat of attack from malicious actors.

Background

Regis University previously hosted and developed information systems infrastructure for CANVAS (Computer and Networking Virtualization and Simulation) cyber competition. This initial foray into this realm of cyber competition development offered insight into how to improve the development of infrastructure for future events including consideration of the project management methodologies. The Regis project team developing cyber competitions improved its approach in developing RMCCDC from lessons learned in the development of CANVAS, such as introducing advanced scenarios based on current threats, prevailing security and networking technologies, and improved monitoring capabilities. But the team fell victim to some of the same mistakes and constraints adversely affecting the effectiveness of monitoring and testing coverage. The network topology for the public and private networks designed for the event made it difficult to monitor full Red and Blue Team activities. As a result, a flat, isolated network will be favored for future events. Testing was hampered by severe time constraints caused by late arrival of necessary equipment and Black Team scheduling difficulties. In order to improve the level of capability of the team, efficiency of work, and quality of outcome, the team decided to apply a standard methodology for a systems development life cycle (SDLC). The reason that the team decided this is because it recognized standard artifacts of project dysfunction in the previous work and realized that a more formal approach was necessary to ensure success. Cyber competitions are a type of product, one from which the host can gain value as well as the various participating teams. During our trial and tribulations in building RMCCDC, we realized that cyber competitions exemplify the goals and challenges of Enterprise Architecture; that is to integrate novel approaches in executing in the most efficient and agile way possible, the strategies for developing of the final product. It is therefore quite clear that an appropriate development lifecycle methodology be leveraged for developing cyber competitions.

Based on the above realization, in 2012, the Regis University Black Team implemented a diluted version (i.e. lacking a full set of phases) of an Agile SDLC, where there is somewhat less formality and a greater emphasis on people and their interactions. Although the Agile Methodology is generally specific to software devel-opment, the same principles can apply to system engineering projects, at least those facets that relate to people and their interactions. Additionally, agile methodologies place strong emphasis on risk management, since projects of any size are rife with risk requiring effective time management, communication and prioritization of tasks. The focus on risk was particularly important to the team because of the need to produce a resilient infrastructure with a volunteer team in a limited time. Extending analysis of these affinities, the next sections present a review of Agile methodologies, and then particularly SCRUM methodologies as applied by the Regis cyber challenge development team along with an evaluation of the change in performance outcomes attributable to the use of the SCRUM methodology.

Agile Software Development Methodologies

Initially, the cyber competition development team did not consider using an agile method to drive development of the competition infrastructure; this came about as we were actively working to get the deliverables completed. We realized later into the process that due to the timeframe, scheduling and manpower availability constraints, we couldn't use a traditional software development lifecycle (SDLC) approach. Since we just started taking part in the CCDC circuit and didn't have experience in developing cyber competitions other than CANVAS we chose to embrace, in an ad-hoc way, the ideals set forth in the Agile Manifesto (http://www.agilemanifesto.org). There are many conceptual and practical parallels between software development and information systems infrastructure development, which includes just about every Internet technology engineering discipline. Therefore, we feel confident that using an agile project management methodology greatly improves the final competition deliverable as well as satisfying several academic objectives for students taking part. We assert that using the SCRUM framework, developed by Ken Schwaber and Jeff Sutherland [START_REF] Pressman | Agile Development. Software engineering, a practitioner's approach[END_REF], would serve the purposes of the competition host best.

SCRUM, An Agile Method

First and foremost, SCRUM is a process framework. More specifically, it is an iterative and incremental agile software development method, so again its focus is on managing software development. Yet, there are parallels with software development and information system infrastructure development such that the same core values and mechanisms of the SCRUM framework can be applied to cyber competition infrastructure. As a result, it serves to take a closer look at how we could have leveraged, and leverage more effectively in the future, the SCRUM management framework for development of RMCCDC infrastructure.

The actionable roles in SCRUM consist of SCRUM Masters, Product Owners, and a Development team [START_REF] Potter | Comparing scrum and cmmi, how they can work together[END_REF]. A SCRUM Master is very much like a "Project Angel" since they enforce process adherence and protect the development team from disruptions that can cause missed deadlines [START_REF] Potter | Comparing scrum and cmmi, how they can work together[END_REF]. There is typically a single Product Owner in the SCRUM framework, a person who is the primary stakeholder. In the case of cyber competitions hosted by schools, the product owner would be the Director of the Computer Information Systems Dept. or pertinent faculty members in charge of meeting obligations agreed to by the University as a new member of the CCDC family. The Development Team would be the Black Team, which is generally comprised of current Practicum students and former alumni volunteers.

In addition to the different SCRUM roles, the other important facet of SCRUM is the iterative process within the SCRUM framework, specifically a concept referred to as a "Sprint." A Sprint is the "heart" of SCRUM and is in essence a time-box of one month or less in which to get things "Done" [START_REF] Schwaber | The scrum guide, the definitive guide to scrum: the rules of the game[END_REF]. A Sprint is completely agile in nature considering that it directly follows the manifesto by embracing "individuals and interactions over processes and tools" [START_REF]The Agile Manifesto[END_REF]. Sprints contain the following characteristics; 1) change control to protect Sprint goals, 2) Development Team composition remains constant, 3) quality goals do not decrease, and 4) the scope may be clarified and renegotiated between Product Owner and Development Team as issues are discovered [START_REF] Pressman | Agile Development. Software engineering, a practitioner's approach[END_REF].

In SCRUM, there is also a concept referred to as a backlog, which defines specific work deliverables that result from the stories defined in the Release Planning phase [START_REF] Pressman | Agile Development. Software engineering, a practitioner's approach[END_REF]. Stories are based on use cases, a carryover from traditional software development requirements definitions. Since we are developing cyber competitions, the primary requirement is contingent on the chosen scenario, in this respect a form of use case, since it models something that exists in the information technology industry, such as a for-profit web application or critical infrastructure (e.g. power utility, railway station, prison, etc.).

How Ad-Hoc SCRUM was applied to RMCCDC

Our initial requirements phase encapsulated the classic SDLC initial requirements phase: to identify the general requirements for the final product and provide enough detail for the system designers to begin designing the solution. The Product Owner, Regis University, along with the development team decided to raise the bar from what we built for the initial foray into cyber competitions, CANVAS. This time out, we introduced elements drawn from the Open Web Application Security Project (OWASP) Top Ten list of web application attack methods (http://www.owasp.org). Therefore, we knew we wanted to build an infrastructure modeled as closely as possible to a public, for-profit web application as well as the expected supporting systems, such as email server, domain controller, FTP server, etc. that an organization would use to satisfy daily business needs. After identifying a model inspired by a real life hacking incident, the aforementioned Steam™/Valve® hack [START_REF] Poeter | Valve's steam forums hacked, not clear if credit card number were stolen[END_REF], we decided to emulate this environment for our scenario. The end product was a web application simulation, one that could be attacked by a Red team and protected by a Blue team. The requirements defined by these systems, their respective configurations, and content would be the backlogs that the development team members would work on. We propose that a SCRUM Master (or multiple depending on the size of the project) be assigned to manage the development of specific components of the environment in order to keep progress on track.

We assigned a SCRUM Master to maintain progress on the web application backlog (including the Apache server, PHP code, database, FTP server, etc.), another SCRUM Master managed the network development, and a third SCRUM Master to manage the business support environments; Windows systems that implement common business support functions such as role-based access control (e.g. Active Directory), email services with Exchange 2007, employee workstations, etc.). We assigned SCRUM Masters based on their core competency and interest level within each discrete technology domain (i.e. network, web application, business support servers, etc) in order to maximize effectiveness. However, the size and complexity of the infrastructure will dictate the necessity for multiple SCRUM Masters. The assignment of SCRUM Masters is greatly dependent on the manpower, competency, and interest level on hand since students may not desire a project manager type of role. The scenario requirements outlined for RMCCDC provided enough detail for the designers in the next phase to identify how they would implement the infrastructure in question. Iteration 0, the phase following the initial requirements phase in the SCRUM process, includes the development of the necessary infrastructure required for the scenario in question. This stage included the acquisition, installation, and configuration of various information systems, including storage area network (SAN) equipment, networking equipment, and virtual infrastructure hosts with various relevant guest operating systems (i.e. Linux and Microsoft Windows) to serve the desired applications. This portion of the development process was not without problems, so the team solved problems as they arose, which necessarily generated a backlog of work that needed to be completed. Due to scheduling issues with our volunteer staff, we utilized email or instant messaging to communicate critical progress or blockers and spaced out our standups to twice a week rather than daily, leveraging Practicum course time for this activity. When necessary, priorities were reset and other important tasks were given favor so that at least some progress would continue. The Product Owner and Development team developed a project plan, network topology diagrams, and system characteristics to be used in the infrastructure. To minimize risk, we pursued the quickest and most cost-effective method to build a working e-commerce web site. We chose Drupal as the web site engine and UberCart as the shopping cart module since they best met our needs at the time. The public-facing web and database servers, along with an IPv6 network, created a sufficiently challenging attack surface for the Blue Teams to protect.

Since CCDC is largely an academic device, the alignment of individual student projects with the development of cyber competition infrastructure is encouraged. For instance, after offering the opportunity to take part in the development, specifically to Practicum participants, it would behoove the Practicum instructor to gather from students their specific areas of interest and/or core competency, so they could be more effectively utilized. After all, a motivated worker is a productive worker. In a sense, we would be "killing multiple birds with one stone," such that students would get graded work in an area of their specific interest while gaining the valuable skill set of building a functioning information system for a real customer -the competition par-ticipants. In other words, they gain some measure of startup experience. Various facets of systems engineering and software development are touched on, such as quality assurance, project management, information security, and systems engineering. As we discuss the Development Iterations phase, it should become clear to the reader how the scholastic endeavors of students are served through their involvement in cyber competition infrastructure development.

In the Development Iterations phase, we implemented the required systems using common-off-the-shelf (COTS) software. We installed and verified the minimum operational levels; that the guest operating system in the virtualization environment would successfully boot, that we were able to install applications and that the applications functioned as we would expect. We then introduced and enumerated vulnerabilities for individual components to be mitigated by the Blue Teams, as well as business injects, tasks performed as part of normal business operations, during the competition. We were mindful of feature creep, we didn't want to block good ideas that come late; rather we prioritized based on value or ease of integration. This again should remind us of the facet of SCRUM that allows for continuous re-evaluation and the promotion of effective additions to the product.

The best way to test the competition environment is to put it through dry runs with mock Red and Blue teams (such as the Black team split into two groups) to verify that the environments built for each team functioned as expected. Our experience with CANVAS was such that we literally crammed what should have been four weeks of testing time into one week. We experienced similar problems with RMCCDC, but mostly because of delays in hardware acquisition that pushed critical portions of the infrastructure, in this case the network, into backlog. The late arrival of equipment and delayed implementation of network resources prevented the necessary stress and penetration testing to ensure confidence that the infrastructure would handle the load during the event. It is clear that the testing portion of the implementation phase was not nearly sufficient for a regional cyber competition, much less a national one. However, the infrastructure held up well during the competition thanks in large part to the effective work completed up-front in the design and implementation of the systems infrastructure.

The next phase of RMCCDC, called the Pre-Release phase in SCRUM, include integration of the various infrastructure components (e.g. network, servers, applications). This integration is a crucial piece of the puzzle since it will be what will be released for use during the competition and must be tested to make sure everything works as expected. In other words, final acceptance testing occurs in this phase. Additionally, all documentation will need to be finalized, such as business injects and instructions for the event i.e. access control, printing availability, communications, rules, etc.

The Production phase would be the actual competition itself. We had several problems, mostly with the network, that caused some unnecessary frustration for pret-ty much everyone. However, strong teamwork and effective troubleshooting saved the day, as we were able to get activities moving pretty quickly after the initial outages. Future cyber competition development must take better care in adhering to each phase of the SDLC, but with a special emphasis on testing and tracking metrics to gauge effectiveness. Agile methodologies, and by extension SCRUM, are quite different from traditional development methodologies in that they favor maximization of return on investment (ROI) rather than satisfaction of requirements [START_REF] Schwaber | The scrum guide, the definitive guide to scrum: the rules of the game[END_REF]. As a result, there are very limited formal metrics or measurements that can be used to track progress or success. In fact, the most formal metric is based on output from SCRUM meetings, short "stand up" sessions that highlight individual efforts. The "stand up" session is meant to stimulate discussion and admission of problems that could affect progress. Stand-ups are also used to discuss progress on "Burn Downs", the term used to define the quantitatively the work remaining in a sprint. SCRUM Masters are expected to perform most of the documentation and performance monitoring since they are not responsible for specific development tasks [START_REF] Brown | Methodologies for Custom Software Development[END_REF].

Capability Maturity Model Integration

There is value in discussing how SCRUM relates to advanced models for information systems development, such as the Capability Maturity Model Integration (CMMI), a product of Carnegie Mellon Institute, is focused on managing continued process improvement in the enterprise. Cyber competition development does not need to reach the higher levels of CMMI, but it is useful to understand how CMMI can relate to this proposal. RMCCDC reached CMMI Level 1, which is basically the same as saying that the final product followed general ad hoc processes. As discussed previously, we recommend reaching a level better than Level 1, since doing so will improve the chances of a successful implementation and maximize the learning potential for students taking part on the Black Team.

Neil Potter of

The Process Group analyzed how SCRUM and CMMI work together [START_REF] Potter | Comparing scrum and cmmi, how they can work together[END_REF]. It turns out that SCRUM, an agile project management framework, fits very well in the first three levels of CMMI. Since our goal with using SCRUM is to improve the successful completion of cyber competition development and to get to the point where it is possible to introduce more sophisticated scenarios, it is obviously useful to be able to speak about performance in CMMI terms. Incidentally, the inclusion of SCRUM and CMMI practices enrich the experience and learning objectives for the Black Team members building the infrastructure.

SCRUM and CMMI Mapping

SCRUM does not cover Levels 4 or 5 in CMMI, and for good reason, because doing so would violate the fundamental tenets of agile life cycle development. SCRUM mandates flexibility and a focus on customer needs, which are often in flux throughout a project life cycle. Therefore, it is not desirable to integrate Level 4 and 5 processes because they are often heavy in measurements and documentation. We would not want project management tasks to take away from the already limited time available to build the infrastructure.

Researchers at the Technical University of Madrid have analyzed and mapped the various phases of SCRUM to levels 1, 2, and 3 of CMMI [START_REF] Coyle | A case study of risk management in agile systems development[END_REF]. The researchers used a novel approach that visualizes quite clearly how well SCRUM covers the various goals of CMMI in the early levels. The mapping in Figure 1, as developed by the Madrid researchers, claims to prove that SCRUM is compatible with CMMI for the primary reason that both life cycle approaches are working towards the same goal -a fully functioning product that meets the customers' needs. Neil Potter takes the mapping a bit further by showing clearly how SCRUM maps to an extent in CMMI Level 3 [START_REF] Potter | Comparing scrum and cmmi, how they can work together[END_REF]. It is easy to see that introducing SCRUM as the framework for developing cyber competitions also satisfies learning objectives related to project management -a net win for the hosting university. We also recognized that proper risk management goes a long way to weeding out potential blockers or constraints so as to increase the chances of successful project completion. Therefore, risk management must be invoked throughout the development process to minimize loss probability.

Risk Management in Cyber Competitions

Risk Identification is generally the first step in risk management, which includes categorizing the potential risks in order to determine which components have the greatest impact on the success or failure of the project [START_REF] Coyle | A case study of risk management in agile systems development[END_REF]. Taken in the context of a cyber competition, an example of a risk would be the choice of network hardware or a specific network design and how it would affect the overall competition experience. For instance, threats such as unavailable network hardware or a poorly designed network would have a negative effect on competition success. Therefore, the network portion of the competition would be a High Risk item, such that several different threats to the network portion of the infrastructure could cause delays in build-out, testing, and dependent tasks (e.g. application development) or cause the final compe-tition infrastructure to have failures during the event, thereby incurring negative reaction to the competition by all participants involved. A matrix should be used to list out all risks and apply a corresponding score, determined from the loss probability, in order to identify priority.

Risk estimation is used to estimate the probability of potential loss [START_REF] Coyle | A case study of risk management in agile systems development[END_REF]. Using the network example, loss estimation would be severe if the network is being built from scratch and less severe as the time goes by and the network build-out nears stability. Therefore, the network portion of the infrastructure should be prioritized above all other infrastructure components. If possible, the network should be built and maintained in a flat, isolated, constant state in order to minimize the problems just described for future events. Once the network is developed and kept stable, less time will be required for testing and more time can be allocated to other more advanced scenario components.

Risk Evaluation is another facet of the risk management process [START_REF] Coyle | A case study of risk management in agile systems development[END_REF]. The goal of evaluating risk is generally understood in two different approaches; 1) to identify the best response, such as a contingency plan, or 2) to undergo risk aversive action that can lead to either reduction or acceptance [START_REF] Coyle | A case study of risk management in agile systems development[END_REF]. Feasibility analysis also comes in handy during risk evaluation, since it helps to identify facets of the competition scenario that may be too difficult to carry out and are best left out of the event (i.e. risk avoidance). Using SCRUM can ease the risk management process by keeping competition developers in synch with deliverable status during daily standups, allowing the ability to change course without adversely impacting the project.

How did we fare in leveraging risk management in RMCCDC? We were effective in identifying the risks and taking steps to either mitigate them or avoid them altogether. Using the same network example, we recognized that changing the network topology and Internet Protocol addressing schemes each time a competition is developed created risk, so we developed a plan to maintain an isolated network that would be maintained in a constant state, with minimal changes. The network would be leveraged for course projects when it is not used for competitions, thereby minimizing the costs associated with unused resources. This practice also allowed us to maintain knowledge of the state of the environment so we could address emerging problems sooner.

Conclusion

There are many benefits to the development and execution of cyber competitions at the collegiate level. They are primarily based on assessing and exercising technical skill in the realm of cybersecurity, but are also effective for students attuned to other information technology disciplines. They offer an unparalleled apparatus for education as well as team and individual skill assessment on technical activities related to system administration, network operations, and software development. How well do team members work together to solve a problem or develop a solution? How well do individual team members handle their respective tasks? These questions can be asked of Blue Teams as well as Black Teams. The development of cyber competition infrastructure is not a trivial undertaking and requires people skilled in information technologies to design, develop, implement and test the infrastructure. Competition infrastructure development is an excellent learning apparatus, in that multiple facets of information technology are touched upon. Thus, students should take a significant part in developing the competition infrastructure because the exercise offers highly valuable skill development.

Scenario details, the theme for the competition, are very important since it will primarily determine the learning objectives in the competition. It is important to mention that they are not easily used as a gauge for large-scale or global assessment of attack techniques or mitigation capabilities due to scope; the cost of equipment, space, and demands related to network isolation. Realism is paramount, but the scope should be focused on the flavor-of-the-month attacks in order to educate about, or assess relevant skill sets against, current attack methods. CANVAS 2011 focused on Smart Grid security and touched on the Stuxnet phenomenon while RMCCDC 2012 focused a bit more on web application security because they were highlights in their respective time periods.

Traditional SDLC methods do not truly fit the characteristics of developing cyber competition infrastructure at the academic level, because traditional methods are often stringent and heavy on documentation, measurements, and formal meetings. A loose group of students, part-time volunteers, and faculty would not be able to follow such a strict and formal project plan. Therefore, SCRUM is an excellent choice for adoption because it was created to ease the difficulty of managing projects that have tight time schedules, fluid requirements, and limited resources, which are all staple characteristics of cyber competition development. Additionally, SCRUM is growing in popularity in the business world due to its success in improving the effectiveness of project management, so the students and volunteers taking part in developing the competition will gain valuable experience with its use. SCRUM is compatible with the first three levels of CMMI, thereby showing that continuous process improvement can be maintained using SCRUM. Additionally, Risk Management techniques should be leveraged to minimize loss probability of cyber competition components. Using the SCRUM framework for developing cyber competition infrastructure will not only improve the successful deployment but also prepare students for following similar frameworks in their future IT careers.

Figure 1 -

 1 Figure 1 -Managing Requirements (Source: Diaz, Mapping CMMI…, Page 10)

White, G. Ph.D., Williams, D., (2005). Collegiate Cyber Defense Competitions. The ISSA Journal, October 2005. Retrieved April 15, 2012 from https://www.issa.org/Library/Journals/2005/October/White,%20Williams%20-%20Collegiate%20Cyber%20Defense%20Competitions.pdf


archive ouverte pluridisciplinaire HAL, est destinée au dépôt

Introduction:

  Amélioration du contrôle postural par une stimulation mécanique imperceptible Edith Ribot-Ciscar, Liliane Borel To cite this version: Edith Ribot-Ciscar, Liliane Borel. Introduction : Amélioration du contrôle postural par une stimulation mécanique imperceptible. XXIIe congrès de la Société Francophone Posture, Equilibre et Locomotion , Dec 2015, Paris, France. hal-01463758

  Enfin, en condition dynamique et sur tapis de mousse, l'application d'un bruit mécanique n'améliorait pas le contrôle postural. Discussion-conclusion Une stimulation mécanique imperceptible appliquée de part et d'autre de la cheville permet d'améliorer le contrôle postural de sujets sains. Un effet accru peut être attendu chez des patients atteints de troubles de l'équilibre.

	RIBOT-CISCAR E., BOREL L (2015). Amélioration du contrôle postural par une
	stimulation mécanique imperceptible. Neurophysiol Clin, 45/4-5: 396.
	Amélioration du contrôle postural par
	une stimulation mécanique imperceptible
	E. Ribot-Ciscar * , L. Borel
	UMR CNRS 7260, laboratoire de neurosciences intégratives et
	adaptatives, Marseille, France
	* Auteur correspondant.
	Résultats En condition statique, chez le sujet testé les yeux fermés, une réduction
	significative des oscillations posturales était
	observée pour l'application de l'un des niveaux de bruits. De plus, l'effet du bruit
	était d'autant plus grand que :
	-les oscillations posturales étaient importantes ;
	-le sujet était plus visuo-dépendant.
	Mots clés : Stimulation mécanique ; Contrôle postural

Adresse e-mail : Edith.Ribot-Ciscar@univ-amu.fr (E. Ribot-Ciscar) L'application de vibrations mécaniques de fréquences aléatoires et faibles amplitudes (appelées « bruit ») sur les tendons des muscles posturaux de la cheville augmente la sensibilité proprioceptive et améliore la détection de mouvements de l'articulation de la cheville. L'objectif de cette étude a été d'analyser les conséquences de l'application de ce bruit sur la stabilisation posturale chez le sujet adulte jeune et en bonne santé. Matériel et méthodes Les analyses ont été réalisées chez 20 sujets dans trois conditions expérimentales : statique, sur tapis de mousse et dynamique (déplacement sinusoïdal de la plate-forme). Quatre niveaux de bruit ont été testés et comparés à la condition de référence (sans bruit). Les analyses ont porté conjointement sur des évaluations posturographiques (surface du centre de pression et analyse spectrale) et sur des évaluations issues de l'analyse du mouvement (variance angulaire et gain des différents segments corporels).

L'


Wen Chai

Edward Chuah

Leonie Dawson

Simpson

Chuah Chai
email: chaiwen.chuah@qut.edu.au

Edward Dawson
email: e.dawson@qut.edu.au

Leonie Simpson
email: lr.simpson@qut.edu.au

Key Derivation Function: The SCKDF Scheme

Keywords: The SCKDF Scheme Key derivation function, cryptographic key, stream cipher

ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

A key derivation function (KDF ) is a basic component of a cryptographic system. It is used to generate one or more cryptographic keys from a private input string; such as a password, Diffie-Hellman (DH) shared secret or non-uniformly random source material [START_REF] Harkins | Network Working Group G. Zorn Internet-Draft Network Zen Intended status: Standards Track Q[END_REF][START_REF] Heer | Host Identity Protocol Version[END_REF][START_REF] Mcgrew | Key Derivation Functions and Their Uses[END_REF][START_REF] Zhu | PKINIT Algorithm Agility[END_REF]. The derived cryptographic keys are then used for maintaining information security and protecting electronic data when it is stored or transmitted. To prevent an adversary gaining any useful information about the private string, it is essential that the cryptographic keys generated by the KDF are computationally indistinguishable from a binary random string [START_REF] Krawczyk | Cryptographic Extraction and Key Derivation: The HKDF Scheme[END_REF]. That is, given a binary string the adversary may not be able to distinguish whether the string is the cryptographic key generated by the KDF or a random string of the same length.

For KDF s, the inputs consist of a private string and a public string. The public string consists of a random string or a concatenation of counter, session identifier or the identities of communicating parties. Where the cryptographic keys are obtained directly from the inputs without any intermediate step, this is refered to as a single phase KDF (see for example [START_REF] Adams | On the Security of Key Derivation Functions[END_REF][START_REF] Chen | Recommendations for Key Derivation Using Pseudorandom Functions[END_REF][START_REF] Kaliski | PKCS# 5: Password-based cryptography specification version 2[END_REF][START_REF] Yao | Design and Analysis of Password-based Key Derivation Functions[END_REF]). A more recent KDF design trend is the two phase KDF [START_REF] Chen | C. Recommendation for Key Derivation through Extractionthen-Expansion[END_REF][START_REF] Krawczyk | Cryptographic Extraction and Key Derivation: The HKDF Scheme[END_REF], where the phases consist of an extractor and an expander. The inputs to the extractor are the private string and a non-secret random string, while the inputs to the expander are the output from the extractor and the context information. In this design, the extractor and expander are two independent sub-functions, which can be designed and analysed separately. This permits mixing and matching of different types of extractor and expander functions to form good extract-then-expand KDF proposals, in terms of both security and/or performance.

Many existing KDF proposals (both single and two phase) are composed using either hash functions or block ciphers. Both hash functions and block ciphers divide the input into a series of equal-sized blocks, with some padding necessary if the last block input is not of the appropriate length. The input blocks are processed in sequence with a one-way compression function, and the output is a fixed block size. A KDF should be able to generate cryptographic keys of arbitrary length. Where the required length is not a multiple of the output block size, modification is necessary. Generally, the approach is to produce multiple output blocks until the required length has been obtained and to discard any bits in excess of the required length. This may be regarded as wasteful.

KDF s are widely used in Internet protocols [START_REF] Harkins | Network Working Group G. Zorn Internet-Draft Network Zen Intended status: Standards Track Q[END_REF][START_REF] Heer | Host Identity Protocol Version[END_REF][START_REF] Mcgrew | Key Derivation Functions and Their Uses[END_REF][START_REF] Zhu | PKINIT Algorithm Agility[END_REF]. Mobile devices like smartphones are increasingly used to access the Internet. These devices have low processing power, so efficiency is important. There is increasing interest in the design of more efficient KDF s for use in mobile devices or similar applications.

Stream ciphers are often used for encryption in resource constrained devices due to their speed and simplicity of implementation in hardware. Hash functions and block ciphers are often slower and require more resources than stream ciphers. Thus, a KDF based on stream ciphers may provide a more efficient alternative to the current block cipher or hash function based KDF s.

This paper proposes a new secure and efficient KDF based on the keystream generator of a stream cipher. We refer to this proposal as SCKDF . We present a generic model for a stream cipher based KDF which is secure if the underlying stream cipher is secure. We implement this generic SCKDF for three stream ciphers proposals: Trivium [START_REF] Canniere | Trivium specifications[END_REF], Sosemanuk [START_REF] Berbain | Sosemanuk, a fast softwareoriented stream cipher[END_REF] and Rabbit [START_REF] Boesgaard | The Rabbit stream cipher. New Stream Cipher Designs[END_REF]. The results show that the SCKDF is executes faster compared to existing KDF s based on hash functions and block ciphers.

This paper is organized as follows. We provide our notation and some background information on KDF s in Section 2. Section 3 reviews the properties of keystream generators. Our new proposal, a generic SCKDF , is presented in Section 4. The security proof for this construction is given in Section 5. Performance measurements to permit comparison of stream cipher, block cipher and hash function based KDF s for common applications scenarios are given in Section 6.

Backgroud for KDFs

Before we present the formal definition of a key derivation function, we recall the notion of min-entropy, as presented in [START_REF] Krawczyk | Cryptographic Extraction and Key Derivation: The HKDF Scheme[END_REF]. Definition 1 (min-entropy) [START_REF] Krawczyk | Cryptographic Extraction and Key Derivation: The HKDF Scheme[END_REF]. A probability distribution X has min-entropy (at least) m if for all a in the support of X and for random variable X drawn according to X , Prob(X=a) ≤ 2 -m .

In our case, X is the random variable represented by the private string and X is the probability distribution for possible values of X.

Definition 2 (Key derivation function).

A key derivation function is defined as: K ← KDF (p, s, c, n), where p is a private string, which is chosen from the space of all possible private strings PSPACE . We denote the length of p as pl. s is a salt, a public random string chosen from the salt space SSPACE . We denote the length of s as sl; c is a public context string chosen from a context space CSPACE . The length of c is cl.

n is a positive integer that indicates the number of bits to be produced by the KDF ; -K is the derived n bit cryptographic key.

The basic operation of a KDF is to transform the secret p and the public inputs (s and/or c) into an n bit string which can be used as a cryptographic key.

Note that all inputs are publicly known, except for the private string p. The salt is uniformly random and is used to create a large set of possible keys corresponding to a given p [START_REF] Yao | Design and Analysis of Password-based Key Derivation Functions[END_REF]. Context information is arbitrary but application specific data; for example, a session identifier or the identities of communicating parties [2,[START_REF] Barker | SP 800-56A. Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography[END_REF]. Similar definition are used in other KDF proposals. See for example [START_REF] Adams | On the Security of Key Derivation Functions[END_REF][START_REF] Chen | Recommendations for Key Derivation Using Pseudorandom Functions[END_REF][START_REF] Kaliski | PKCS# 5: Password-based cryptography specification version 2[END_REF][START_REF] Yao | Design and Analysis of Password-based Key Derivation Functions[END_REF][START_REF] Chen | C. Recommendation for Key Derivation through Extractionthen-Expansion[END_REF] and [START_REF] Krawczyk | Cryptographic Extraction and Key Derivation: The HKDF Scheme[END_REF]. Definition 3 A KDF function is called (t, q, )m-entropy secure if it is (t, q, )secure with respect to all (computational)m-entropy sources, where the derived cryptographic key of the KDF from m-entropy sources is computationally indistinguishable from a binary random string. That is, when the adversary is given a limited number of queries (q in total) to polynomial time algorithm t, the adversary can distinguish between the cryptographic key derived from the KDF or a random string of the same length with negligible probability [START_REF] Krawczyk | Cryptographic Extraction and Key Derivation: The HKDF Scheme[END_REF].

Single Phase KDFs

A single phase KDF uses a pseudorandom function that takes the private input and public inputs and transforms these inputs directly into one or more variable length computationally indistinguishable cryptographic keys. Figure 1 depicts a single phase KDF . Definition 4 (Single phase KDF). A KDF is a function of F : {0, 1} pl × {0, 1} sl × {0, 1} cl → {0, 1} * from a set p ∈ R PSPACE mapping to an arbitrary length of string {0, 1} * . The string should be indistinguishable from random strings of the same length in polynomial time.

Two Phase KDFs

A two phase KDF is the composition of two subfunctions: an extractor (Ext) and an expander (Exp). Note that the output of the extractor is an input to the expander as shown in Figure 2. The typical construction of a two-phase KDF is: KDF (p, s, c, n) = Exp ({Ext (p , s)}, c, n). We discuss each phase below. Extractor The aim of the extractor is to transform the private input p into close to uniformly random output, which we denote as PRK . In this research, we generate the PRK from p using a computational extractor.

Definition 5 (Computational extractor) [START_REF] Krawczyk | Cryptographic Extraction and Key Derivation: The HKDF Scheme[END_REF]. Let PSPACE and SSPACE be set spaces of {0, 1} pl and {0, 1} sl respectively. A function Ext : {0, 1} pl × {0, 1} sl → {0, 1} kl is called a (t X , X )-computational extractor if an adversary A running in polynomial time t X can distinguish between PRK (derived from p) or a random string of the same length, with probability not larger than ( 12 + X ) where p is chosen from {0, 1} pl and s chosen from {0, 1} sl . If Ext is a (t X , X )-computational extractor with min-entropy m we call it a (m, t X , X )-computational extractor.

Expander The expander takes the arbitrary length output from the extractor phase, PRK , as an input together with other public input material (context information) and generates one or more arbitrary length computationally indistinguishable cryptographic key(s). Definition 6 (Expander) [START_REF] Krawczyk | Cryptographic Extraction and Key Derivation: The HKDF Scheme[END_REF]. An expander is a (t Y , q Y , Y )-secure variablelength-output pseudorandom function family if an adversary A running in polynomial time t Y and making at most q Y queries to the expander can distinguish the cryptographic key is generated by the expander or a random string of the same length with probability not larger than ( 1 2 + Y ).

The Security of KDF

The major security goal for a KDF is that the cryptographic keys generated by the KDF are indistinguishable from truly random binary strings of the same length, even when the public inputs are provided to the adversary. We follow the approach of Krawczyk [START_REF] Krawczyk | Cryptographic Extraction and Key Derivation: The HKDF Scheme[END_REF] and define the KDF security through a distinguishing game played between a challenger C and an adversary A in polynomial time algorithm t. The KDF is considered secure if no A can win the distinguishing game with probability significantly greater than the probability of winning by guessing randomly. The game runs in three major stages: the learning stage, the challenge stage and the adaptive stage as shown in Table 1. During the learning stage, A is allowed to interact with C to demand cryptographic keys corresponding to A's choice of public input c with p and s chosen by C. In this game, p is secret known only to C, while s is known by A. At the challenge stage, A is provided a challenge output K . After receiving the challenge output, A is in the adaptive stage. A can continue the same process as in the learning stage, subject to the choice of public input (c) being different from the public input chosen in the challenge stage. Lastly, A has to distinguish whether the challenge output is the derived cryptographic key from the KDF or just a random string. We describe a KDF for which A cannot win this game with the probability not larger than ( 12 + ) as CCS-secure. Definition 7 (CCS-secure) The KDF is (t, q, ) CCS-secure if for all probabilistic polynomial-time t adversaries A can make at most q < |CSPACE | queries to the KDF who can win the following indistinguishability game with probability not larger than ( 1 2 + ).

Learning 1. C chooses p ← PSPACE . stage 2. C chooses s R ← SSPACE . 3.
A is provided with the value s. 4. For i = 1, . . . , q ≤ q, (4.1)

A chooses ci ← CSPACE . (4.2) C computes Ki = F (p, s, ci, n). (4.3)A is provided the derived cryptographic key, Ki. Challenge 1. A chooses c ← CSPACE stage (subject to restriction ctx / ∈ ci, . . . , c q ). 2. C chooses b R ←{0, 1}. (2.1) If b = 0, C outputs K = F (p, s, c, n), (2.2) else C outputs K R ← {0, 1} n . 5. C sends K to A. Adaptive 1.
Step 4 in Learning stage is repeated for up to q -q queries (subject to restriction ci = c). Table 1. CCS-secure.

In [START_REF] Krawczyk | Cryptographic Extraction and Key Derivation: The HKDF Scheme[END_REF], Krawczyk showed the condition under which a two-phase KDF can be considered CCS-secure as follows in Theorem 1.

Theorem 1 Let Ext be a (t X , X )-computational extractor with the respect to the private string p and Exp a (t Y , q Y , Y )-secure variable-length-output pseudorandom function family, then the above extract-then-expand KDF scheme is (min{t X , t Y }, q Y , X + Y )-CCS secure with the respect the private string p [START_REF] Krawczyk | Cryptographic Extraction and Key Derivation: The HKDF Scheme[END_REF].

Existing KDF Proposals

To date, both single phase and two-phase proposals of KDF s have been based on cryptographic hash functions [START_REF] Krawczyk | Cryptographic Extraction and Key Derivation: The HKDF Scheme[END_REF] and block ciphers [START_REF] Chen | Recommendation for Key Derivation Using Pseudorandom Functions[END_REF]. Hash functions are widely used for data authentication and block ciphers for data confidentiality.

We describe two specific well-known two-phase KDF proposals, one based on hash functions and the other one based on block ciphers, in the remainder of this section.

Hash Functions: In [START_REF] Krawczyk | Cryptographic Extraction and Key Derivation: The HKDF Scheme[END_REF], Krawczyk formalized a KDF using HMAC-SHA families (HKDF) and proved that HKDF is CCS-secure. The proposed HKDF consists of a computational extractor and a pseudorandom expander. The extractor function is

PRK ⇐ Ext p (s) : F ((s ⊕ opad) F ((s ⊕ ipad)||p))
, where F denotes a hash function, ⊕ denoter exclusive or (XOR), and denoter concatenation.

The expander phase of the HKDF functions is

Exp PRK (c, n) : K(1) ⇐ F (PRK ⊕ opad) F ((PRK ⊕ ipad)||c||0
) and F is the hash function. If n > f l, two or more iterations are necessary until the required length has been obtained:

K(i + 1) ⇐ F ((PRK ⊕ opad) F ((PRK ⊕ ipad)||K(i)||c||i)), 1 ≤ i < t, where t = n f l .
The first n bits of the outputs K(1)||K(2)|| . . . ||K(t -1) are used as the cryptographic key, and the remaining bits are discarded.

Block Ciphers: The AES-CMAC based KDF is described in NIST SP800-108 [START_REF] Chen | Recommendation for Key Derivation Using Pseudorandom Functions[END_REF]. The AES block cipher supports key sizes of 128, 192 and 256 bit and has an output size of 128 bits. The AES-CMAC based extractor can be either AES-128, 192 or 256, but the expander is fixed to use AES-128.

During the extraction phase, the input p is broken up into 128 bit blocks denoted as D i , 1 ≤ i < t, t = pl 128 ; and the salt s is used as the AES key. The D i are processed sequentially by using AES. The process is

PRK i = F s (PRK i-1 ⊕ D i ),
where F is AES (128 or 192 or 256), 1 ≤ i < t and PRK 0 = 0 128 .

During the expansion, the PRK and c are the inputs to the expander phase, where c is broken into D i blocks, 1 ≤ i < t, t = cl 128 . PRK is used as the AES key. The extractor function is as below:

K(i) ⇐ F PRK (K i-1 ⊕ D i ) where F is AES-128, 1 ≤ i < t and K(0) = 0 128 . The last block of operation is K(t) = F PRK (K t-1 ⊕ D t ⊕ K b ), b ∈ {1, 2}.
If n > 128, more iterations are performed until the length of output obtained exceeds the required length. Then, the left-most n bits of the output are used as the cryptographic key and the remaining bits are discarded.

A pseudorandom keystream generator is one of the components of a stream cipher. The inputs to the pseudorandom keystream generator are a secret key and a known initial value (IV) and the output is a pseudorandom keystream as shown in Figure 3. The aim of the secure stream cipher is to use a pseudorandom keystream generator which approximate an ideal pseudorandom as defined in Definition 8 and Definition 9. Note that although the keystream output can be produced in bits, bytes or words, we consider the keystream as a binary string: Z 1 , Z 2 , . . . , Z t , where Z i ∈ {0, 1}, i = 1, 2, . . . , t. Definition 8 (Keystream generator). Let KEYSPACE , IVSPACE , ISSPACE , ZSPACE be a set space over {0, 1} k , {0, 1} i , {0, 1} is and {0, 1} * respectively. A keystream generator is a pseudorandom generator (Definition 9) that takes the inputs key and IV and generates arbitrary length of keystream. Pseudorandom keystream generator: {0, 1} k × {0, 1} i → {0, 1} is → {0, 1} * . Definition 9 (Ideal pseudorandom generator) [START_REF] Menezes | Handbook of applied cryptography[END_REF]. An ideal pseudorandom generator is said to pass all polynomial-time statistical tests if no polynomial-time algorithm can correctly distinguish between an output sequence of the generator and a truly random sequence of the same length with probability not larger than 1 2 + , for some negligible value .

Stream Cipher Based KDF

Our proposed SCKDF is a two-phase model where both the extractor and the expander are based on keystream generators for stream ciphers. For stream ciphers, the pseudorandom keystream generator takes two inputs: a key and an IV. In our SCKDF , we replace the pair of inputs to the pseudorandom keystream generator (key, IV) with the input pair (p, s) for the extractor phase and the input pair (PRK , c) for the expander phase. Detailed descriptions and specification for these phases are as follows.

Extractor

In this section, we propose an extractor based on the pseudorandom keystream generator for a stream cipher. The extractor takes p and s as the inputs and produces an output sequence PRK . Let v and w denote the key size and IV size respectively, for the stream cipher. Similarly, let r denote the key size of the stream cipher in the expander phase. (Note that is possible the same stream cipher may be used for both extractor phase and expander phase, but this is not necessary.) Figure 4 depicts our proposed stream cipher based extractor. The extractor process is as follows. A. Use the first v bits of D i as the key and remaining w bits of D i as the IV for the pseudorandom keystream generator. B. Generate v + w bits of keystream. C. The v + w bits of keystream is XORed with D i+1 of p. D. i := i + 1.

Output:

-An r-bit string, denoted PRK .

Expander

In this section, we describe a stream cipher based expander. This function takes inputs the output of extractor phase PRK , together with an arbitrary length binary string c, the context information. The expander output is a pseudorandom binary string. Let v and w denote the key size and IV size respectively for the stream cipher. Figure 5 illustrates our proposed stream cipher based expander. The expander process is as follows.

1. Input: PRK , c, cl, and n.

-If c is null, then c is padded with '0's, cl = w.

Process:

(a) The context information c is divided into blocks, where each block size is of length of w. Let D i denote the i th block of c. The total number of blocks is L = cl w . If the length of the last block D L is less than w bits, the block is padded with '0's.

i. If L = 1. A. Use PRK (from the extractor phase) as the key and c as the IV for the pseudorandom keystream generator. B. Generate n bits of keystream. C. Proceed to Step 3. ii. Else, if L > 1.

A. Use PRK (from the extractor phase) as the key and the first block D 1 as the IV for the pseudorandom keystream generator. B. Generate v bits of keystream. A. Use v bits of keystream as the key and the D i the IV for the pseudorandom keystream generator. B. Generate v bits of keystream. C. i := i + 1. 3. Output: An n-bit binary string suitable for use as a cryptographic key.

The Security of SCKDF

Our proposed two-phase (extract then expand) SCKDF makes use of the pseudorandom keystream generator of a stream cipher in each phase. We assume this is an ideal keystream generator (satisfying Definition 8 and Definition 9 in Section 3). Note that, a similar assumption of an ideal primitive was also made by Krawczyk in proving Theorem 1 in [START_REF] Krawczyk | Cryptographic Extraction and Key Derivation: The HKDF Scheme[END_REF].

For such a pseudorandom keystream generator the SCKDF proposed in Section 4 can be considered as CCS-secure.

Theorem 2 Let pseudorandom keystream generator be a keystream generator from a family of pseudorandom keystream generator which satisfy Definition 8 and Definition 9. If an extract-then-expand SCKDF is built from the pseudorandom keystream generator, then the extract-then-expand SCKDF scheme is (min{t X , t Y }, q Y , X + Y )-CCS secure with the respect to the private string p.

Proof: To satisfy the conditions of Theorem 1, we need to show, i The extractor is a (t X , X )-computational extractor. ii The expander is a (t Y , q Y , Y )-secure variable-length-output pseudorandom function family.

To prove (i) we assume that extractor is not a (t X , X )-computational extractor. This would imply that an adversary A has a polynomial time method to distinguish whether PRK is derived from p or a random string of the same length. For the underlying pseudorandom keystream generator this would then imply that the adversary has a polynomial time method to distinguish between PRK and a truly random string. This contradicts the assumption that pseudorandom keystream generator satisfies Definition 9. Hence (i) is true. Similarly, we can show (ii) is true. Hence by Theorem 1 the SCKDF built from pseudorandom keystream generator is (min{t X , t Y }, q Y , X + Y )-CCS secure with the respect to the private string p.

Performance Measurement

In order to compare the performance of stream cipher, hash function and block cipher based KDF s, we conducted experiments involving measuring the execution time taken to generate n bits of cryptographic key from p, s and c. The stream ciphers include the e-Stream finalists Trivium [START_REF] Canniere | Trivium specifications[END_REF], Sosemanuk [START_REF] Berbain | Sosemanuk, a fast softwareoriented stream cipher[END_REF] and Rabbit [START_REF] Boesgaard | The Rabbit stream cipher. New Stream Cipher Designs[END_REF]. It should be noted that to date these has been no significant security flaws discovered with any of these three stream ciphers. Hence any of these three stream ciphers seem to offer suitable pseudorandom keystream generator generators on which to build our SCKDF model in Section 4. The hash functions are SHA families and block cipher used is AES128. The code of the stream ciphers, hash functions and block ciphers are retreived from [START_REF] Robshaw | The eSTREAM Project. New Stream Cipher Designs[END_REF], [START_REF] Eastlake | US secure hash algorithms[END_REF] and [START_REF] Song | INTERNET DRAFT Ibaraki University Expires[END_REF] respectively. The lengths of the four parameters (p, s, c and n) are taken from the applications below:

-Application 1: Host identity protocol version 2(HIPv2) is based on the DH shared secret key exchange protocol, which provides secure communications and maintains shared IP-layer state between two separate parties [START_REF] Heer | Host Identity Protocol Version[END_REF]. The cryptographic keys are generated using KDF and the inputs are as below:

• The tunneled extensible authentication method (TEAM) is a method that securing communication between peer and server by using transport layer security (TLS) to establish a mutually authenticated tunnel [START_REF] Harkins | Network Working Group G. Zorn Internet-Draft Network Zen Intended status: Standards Track Q[END_REF]. The inputs to the KDF are as below:

• Exp 9 : p = 40 bytes, s = 32 bytes, c= null, n = 128 bytes

Software Performance

For all nine experiments the time is recorded for each of 100 trials. The average time (mean) and standard deviation for each experiment are presented in Table 6.1. The execution time was captured using CLOCK MONOTONIC (which can be found in the programming language C library). All the simulations were performed at a machine with the following specifications: Intel (R) core (TM) 2 duo CPU E8400 @ 3.00GHz 2.99 GHz, 4GB RAM and in 64 bit OS. Table 6.1 shows the software performance of KDF s based on three different cryptographic primitives. The three cryptographic primitives are stream cipher, hash function and block cipher. The execution time for Exp 9 was relatively faster compare with Exp 1-8 for all KDF proposals. This is due to the inputs length in Exp 9 being shorter than the input lengths for Exp 1-8. Overall, the execution time for all types of KDF increases, when the lengths of the inputs (p, s, c or n) increase.

Another observation from this table is the performance results show that all three stream cipher based KDF 's were significantly more efficient in software than either the hash function or block cipher based KDF 's. While, the most efficient KDF is the Trivium based KDF and the slowest KDF is block cipher based KDF .

KDFs/Exp

Hardware Performance

This section presents hardware implementation and performance metrices for stream ciphers, hash functions and block ciphers. Note that, the hardware performance comparison is not the hardware performance of the actual KDF proposals. Rather it represents the hardware performance of the underlying cryptographic primitives obtained from existing literature. The result shows that Trivium requires less resource and has highest throughput, while SHA384 and SHA512 requires the highest resource in hardware. These results indicate that a hardware based KDF designed from Trivium using the SCKDF model would offer significant advantages over other designs in hardware. Table 3. Hardware Performance of Hash Functions, Block Ciphers and Stream Ciphers.

Conclusion

A KDF is an essential component in generating cryptographic keys for safeguarding data storage and transmission over insecure channel. To be capable of working better on mobile devices such as smartphones, pocket PC and mobile phones, we proposed a lightweight KDF based on stream ciphers. Stream ciphers are often faster and require less resources which are suitable operated at low processing power and memory constrained devices, for example mobile devices. In this research, we have demonstrated that our newly proposed KDF based stream ciphers are secure if the underlying stream cipher are secure and more efficient compared to existing KDF proposals. From our analysis to date a SCKDF design based on Trivium cipher would be secure and efficient both in software and hardware.

Fig. 1 .

 1 Fig. 1. Single phase model for KDFs.

Fig. 2 .

 2 Fig. 2. Extract-then-expand model for KDFs.

stage 2 .

 2 A outputs b = 0, if A believes that K is cryptographic key, else outputs b = 1. A wins the game if b = b.

Fig. 3 .

 3 Fig.3. Keystream Generator[START_REF] Stallings | Cryptography and Network Security: Principles and Practices, Fourth Edition[END_REF]

Fig. 4 .

 4 Fig. 4. Extractor based on stream ciphers 1. Input: p, s, pl, sl, r. 2. Process: (a) If s is null. i. Divide private string p into blocks, where each block is of length of v + w. Let D i denote the i th block of p. The total number of blocks is L = pl v+w . If the length of the last block D L is less than v + w bits, the block is padded with '0's. Go to Step 2c. (b) Else (if s is not null). Public string s is proposed to have same length as w of pseudorandom keystream generator. However, if sl < w , set the remaining bits with '0's. i. If pl < v. A. Pad the remaining bits of p with '0's. B. Use the p as the key and s as the IV for the pseudorandom keystream generator. C. Generate r bits of keystream. D. Proceed to Step 3. ii. Else, if pl > v.A. Use the first v bits of p as the key and s as the IV for the pseudorandom keystream generator.

Fig. 5 .

 5 Fig. 5. Expander based on stream ciphers

  Exp 1 : p = 128 bytes, s = 8 bytes, c= 32 bytes, n = 64 bytes • Exp 2 : p = 128 bytes, s = 8 bytes, c= 32 bytes, n = 192 bytes • Exp 3 : p = 256 bytes, s = 8 bytes, c= 32 bytes, n = 64 bytes • Exp 4 : p = 256 bytes, s = 8 bytes, c= 32 bytes, n = 192 bytes -Application 2: PKINIT is applied in Kerberos protocol [24]. The inputs to the KDF are as below: • Exp 5 : p = 128 bytes, s = null, c= 64 bytes, n = 64 bytes • Exp 6 : p = 128 bytes, s = null, c= 64 bytes, n = 192 bytes • Exp 7 : p = 256 bytes, s = null, c= 64 bytes, n = 64 bytes • Exp 8 : p = 256 bytes, s = null, c= 64 bytes, n = 192 bytes -Application 3:

Table 2 .

 2 54947.72 116787.15 60843.54 119729.85 59245.68 119497.2 60870.97 122340.7 74657.5 S 1926.55 29908.35 1965.87 59220.04 5220.38 6334.94 2106.51 6051.33 1491.43 AES128 x 236657.29 500199.78 330521.48 580804.49 322538.33 753565.93 410619.75 830594.7 148952.35 S 12451.69 25568.83 41150.53 25316.09 10485.70 22020.28 21595.07 4468.46 52170.44 *Performance time is in nanosecond. x and S are sample mean and standard deviation respectively Software Performance of KDF.

		Exp 1	Exp 2	Exp 3	Exp 4	Exp 5	Exp 6	Exp 7	Exp 8	Exp 9
	Trivium x 12185.15 12886.61 19798.71 20623.36 14967.07 15829.43 21396.72 22628.53 4900.05
		S 1761.62 2575.09 1293.19 2178.31 1276.21 2605.27	219.91	4169.30	311.00
	Sosemanuk x 18494.99 19237.54 30231.75 30153.16 20828.66 21714.94 33749.51 32449.32 8089.25
		S 2182.31 2040.69 5459.62 2906.47 2199.21 2547.35 8761.57 3162.79	165.06
	Rabbit x 26307.11 26296.78 33691.33 36346.68 29845.23 31898.28 43679.73 43559.88 7825.69
		S 7024.60 1482.73	297.45	4245.17	277.67	1904.01 6523.79 3069.62	231.41
	SHA1	x 39583.75 79485.76 41267.27 83951.21 45068.91 96129.51 47816.59 99010.69 56364.39
		S 6129.62 1341.97 1422.08 2333.11 3489.43 1558.77 1429.24	712.13	5777.41
	SHA224 x 39327.14 77271.78 44264.8 82551.63 43258.77 80919.54 35060.03 74216.05 48076.72
		S 2453.69 1789.89 6180.79 16942.54 6144.87 1749.19 1519.05	668.50	1592.78
	SHA256 x 29756.25 68713.71 33140.46 72019.25 32685.35 72101.38 36264.51 75328.13 40487.08
		S 1581.87 2270.14 1384.51 1903.90 5763.42 4108.59 5491.55 3262.97 1540.99
	SHA384 x 82538.02 137821.08 84262.56 143402.09 83547.43 142936.8 89696.46 149876.24 96146.69
		S 3711.42 25900.93 1900.20 58864.25 1111.95 8541.55 1959.77 13847.19 556.55
	SHA512 x


Zhu Huafei

Ng Wee-Siong

See-Kiong Ng

Uspo

Sustainable Pseudo-random Number Generator

Keywords: Provable security, Robust pseudo-random number generator, Sustainable pseudo-random number generator

have proposed an efficient architecture for robust pseudorandom generators that ensure resilience in the presence of attackers with partial knowledge or partial controls of the generators' entropy resources. The BH scheme is constructed from the Barak, Shaltiel and Tromer's randomness extractor and its security is formalized in the simulation-based framework. The BH model however, does not address the scenario where an attacker completely controls the generators' entropy resources with no knowledge of the internal state. Namely, the BH security model does not consider the security of bad-refresh conditioned on compromised = false. The security of such a case is interesting since if the output of the protocol conditioned on compromised = false looks random to the attacker, then the proposed scheme is secure even if the attacker completely controls entropy resources (recall that attackers with partial knowledge or partial controls of the generators' entropy resources in the BH model). The BH scheme is called sustainable if the above mentioned security requirement is guaranteed. This paper studies the sustainability of the BH pseudorandom generator and makes the following two contributions: in the first fold, a new notion which we call sustainable pseudorandom generator which extends the security definition of the BH's robust scheme is introduced and formalized in the simulation paradigm; in the second fold, we show that the BH's robust scheme achieves the sustainability under the joint assumptions that the underlying stateless function G is a cryptographic pseudorandom number generator and the output of the underlying randomness extractor extract() is statistically close to the uniform distribution.

Introduction

Randomness is essential for security protocols and pseudorandom generators are used to generate random bits from short random seeds [START_REF] Goldreich | Foundation of Cryptography[END_REF][START_REF] Goldreich | Foundation of Cryptography[END_REF]. A randomness generator, usually is defined over a randomness extractor which in turn is defined over certain mathematical assumptions (e.g., cryptographic hash functions and one-way functions [START_REF] Blum | How to Generate Cryptographically Strong Sequences of Pseudo Random Bits[END_REF][START_REF] Andrew | Theory and Applications of Trapdoor Functions (Extended Abstract[END_REF][START_REF] Barak | True Random Number Generators Secure in a Changing Environment[END_REF][START_REF] Barak | A model and architecture for pseudorandom generation with applications to /dev/random[END_REF][START_REF] Goldreich | Monotone Circuits: One-Way Functions versus pseudorandom Generators[END_REF][START_REF] Kamp | Deterministic extractors for small-space sources[END_REF][START_REF] Boldyreva | A New pseudorandom Generator from Collision-Resistant Hash Functions[END_REF][START_REF] De | Extractors and Lower Bounds for Locally Samplable Sources[END_REF][START_REF] Salil | Characterizing pseudoentropy and simplifying pseudorandom generator constructions[END_REF] and the references therein). The reality, however is that procedures for cryptographic systems to obtain random strings are often not well designed [START_REF] Gutterman | Analysis of the Linux Random Number Generator[END_REF][START_REF] Dorrendorf | Cryptanalysis of the windows random number generator[END_REF][START_REF] Goldberg | Randomness and the Netscape Browser[END_REF].

Considering a scenario, where a Trusted Platform Module (TPM) is used to collect high-entropy resources so that randomness can be extracted from the generated high-entropy resource (notice that the assumption of high-entropy source is a necessary condition for extracting randomness. This is because one cannot extract m bits from a distribution source with min-entropy less than m). Let X be a random variable describing possible outputs of the TPM in a specified environment. Ideally, we would like the adversary not to be able to influence the distribution of X at all so that the original design for generating high-entropy resource is guaranteed. However, in a realistic setting an adversary may have some control over the environment in which the device operates, and it is possible that changes (e.g., temperature, voltage, frequency, timing, etc.) in this environment affect the distribution of random variable X.

Barak, Shaltiel and Tromer [START_REF] Barak | True Random Number Generators Secure in a Changing Environment[END_REF] formalized the mathematical mode for the adversary's influence on the source and then proposed an efficient construction of randomness extractors that aim to extract randomness from high entropy resources. They have shown that their randomness extractors work for all resources of sufficiently high-entropy, even the specified resources are correlated. Barak and Halevi [3] then presented formal models and architectures for robust pseudorandom generators (a pseudorandom generator is robust if it is resilient in the presence of attackers with partial knowledge or partial controls of the generators' entropy resources). The Barak and Halevi's (BH) pseudorandom generator consists of the following two algorithms -A function next() that generates output r ((r, s ) ← next(s)) and then updates the state s accordingly; The goal of this component is to ensure that if an attacker does not know the current state s then the output should be random form the point view of the attacker. Typically, next() is a deterministic algorithm given an initial state s 0 . It is well-known that there exists no single deterministic randomness extractor for all high-entropy resources X and hence the design of next() function is a non-trivial task [START_REF] Barak | True Random Number Generators Secure in a Changing Environment[END_REF][START_REF] Barak | A model and architecture for pseudorandom generation with applications to /dev/random[END_REF]. -A function refresh() that refreshes the current state s using some additional input x (s ← refresh(s, x)). The goal of this component is to ensure that if the input x is from a high-entropy resource then the resulting state is unknown to the attacher.

The motivation problem

The security of Barak and Halevi's robust pseudorandom generator is formalized in the simulation-based framework. The security game begins with the system player initializing s = 0 m and compromised =true and then the attacker interacts with the system using the following interfaces:

good-refresh(D) with D a distribution in high entropy source H. The system resets compromised =false. bad-refresh(x) with a bit string x. If compromised = true then the system sets s = refresh(s, x) and updates the internal state to s . Otherwise (if compromised = false) it does nothing;

set-state(s ) with an m-bit string s . If compromised = true then the system returns to the attacker the current internal state s, and if compromised = false then it chooses a new random string s ← R {0, 1} m and returns it to the attacker. Either way, the system also sets compromised = true and sets the new internal state to s . next-bits(). If compromised = true then the system runs (r, s ) = next(s), replaces the internal state s by s and returns to the attacker the m-bit string r. If compromised = false then the system chooses a new random string r ← R {0, 1} m and returns it to the attacker.

Recall that in the ideal world (in the BH model), when an attacker invokes bad-refresh conditioned on compromised = false, the system does nothing while in the real world scenario, even if the attacker invokes bad-refresh conditioned on compromised = false, the pseudorandom generator scheme will output a refresh statement s = refresh(s, x). If we consider the security of bad-refresh(x) conditioned on compromised = false, then there is a security gap between the real-world scenario and the ideal-world scenario in the BH model. Notice that this gap between the ideal world scenario and the real world sceario does not imply that the BH scheme is insecure since the security definition in the BH model does not encompass such a scenario.

This work

At first glance, a formalization of sustainable pseudorandom generator is trivial since the state s of the current interface bad-refresh(x) conditioned on compromised = false is unknown to the attacker in the BH model. We however, aware that to define an output of bad-refresh(x) conditioned on compromised = false, the following scenarios must be carefully considered at least one invocation of good-refresh(D) with D in high entropy resource H has been called before the current invocation of the bad-refresh(x) with input x since the initial state of the BH system is 0 m which is publicly known and compromised =true. possible many invocations of next-bits() have been called since the flag defined in the BH model remains compromised = false in each next-bits() invocation.

no set-state(s ) with input s is invoked between the latest good-refresh(D) invocation and the current bad-refresh(x) with input x and compromised = false invocation;

As a result, the output of bad-refresh(x) with input x and compromised = false from the point view of the adversary conditioned on the unknown of the current state s should be determined by the transcripts of invocations of the interfaces defined above. Before we define a possible output of bad-refresh(x), we would like first to consider the following interesting cases -Case 1: Suppose there are total l 1 calls of good-refresh(D). The transcript of the l 1 invocations can be expressed in the following form:

s 1 = refresh(s 0 , x 0 ), s 2 = refresh(s 1 , x 1 ), • • • , s l1 = refresh(s l1-, x l1-1 )
, where s 0 is the initial state and x 0 , . . . , x l1 are selected from the high entropy source H. Notice that (s 1 , . . . , s l1 ) are kept secret to the attacker. -Case 2: Suppose there are total l 2 calls of next-bits(). We further consider the following two cases: Case 2.1: if compromised = true then the system runs (r, s ) = next(s), replaces the internal state s by s and returns to the attacker the m-bit string (r, s ). More precisely, let s 0 be the initial state that is known to the attacker, then the transcript can be expressed in the following form: (r 1 , s 1 ) = next-bits(s 0 ), (r 2 , s 2 ) = next-bits(s 1 ), • • • , (r l2 , s l2 ) = next-bits(s 12-1 ). Case 2.2: if compromised = false then the system runs (r, s ) = next(s), replaces the internal state s by s and returns r but not s to the attacker. More precisely, if s * 0 is unknown to the attacker (here we assume that s * 0 is obtained by invoking good-refresh(D) interface), then the transcript can be expressed in the following form: (r

1 , s 1 ) = next-bits(s * 0 ), (r 2 , s 2 ) = next-bits(s 1 ), • • • , (r l2 , s l2 ) = next-bits(s 12-1 ).
Notice that the transcripts useful to the attacker are those generated in Case 2.2 since the transcripts in Case 2.1 can be computed by the attacker itself while the transcripts in Case 1 reveal nothing other than notices of the activated executions. We will define an output of bad-refresh(x) conditioned on compromised = false a random string. This is because computational indistinguishability is preserved by efficient algorithms. The challenging task now is whether the BH's pseudorandom generator is sustainable? Luckily, we are able to show that the Barak and Halevi's robust pseudorandom generator is sustainable under the joint assumptions that the underlying stateless function G is a cryptographic pseudorandom number generator and the output of the underlying randomness extractor extract() is statistically close to the uniform distribution.

Road-Map: The rest of this paper is organized as follows: the notion of sustainable pseudorandom generator is first introduced and formalized in Section 2; We then show that the Barak and Halevi's robust pseudorandom generator is sustainable assuming the existence of cryptographic pseudorandom number generators and the t-resilient extractor and we conclude this work in Section 4.

Sustainable pseudorandom generators

In this section, we first recall the robust pseudorandom generator due to Barak and Halevi, and then provide a formal definition of sustainable pseudorandom generators

The Barak and Halevi's construction

In the high level, Barak-Halevi's framework consists of two functions: next(s) that generates the next output and then updates the state accordingly; and refresh(s, x) that refreshes the current state s using some additional input x.

-A next function next takes as input a sate s ∈ {0, 1} m to generate a pair (r, s ), where r is an l-bit string and s is an m-bit state. next then outputs r and replaces s the internal state by the new state s . -A refresh function refresh takes as input (s, x) to generate a new state s , where s ∈ {0, 1} m and x ∈ {0, 1} n . refresh then updates the state with s .

Definition 1. Given a collection H = {h λ } λ∈Λ of functions h λ : {0, 1} n → {0, 1} m , we consider the probability space of choosing λ ∈ R Λ. For every x ∈ {0, 1} n , we define the random variable R x = h λ (x). We say that H is an l-wise independent family of hash functions if:

for every x, R x is uniformly distributed in {0, 1} m ; -{R x } x∈{0,1} n are l-wise independent.

Lemma 1. (due to Barak, Shaltiel and Tromer [START_REF] Barak | True Random Number Generators Secure in a Changing Environment[END_REF]) Let X be a random variable.

Let Pr[X = x] be the probability that X assigns to an element x. Let H ∞ (X) = log( Pr[X=x] ). Let H ={h λ } λ∈Λ be a family of l-wise independent hash functions from n bits to m bits, l ≥ 2. If H ∞ (X) ≥ k, then for at least a 1 -

1 max x∈X
2 -u fraction of λ ∈ Λ, h λ (X) is -close to uniform for u = l 2 (k -m -2 log( 1 ) - log(l) + 2) -m -2).
The function h λ (X) is called randomness extractor. To implement the next function next and refresh function refresh, Barak and Halevi first invoke the following standard cryptographic pseudorandom generator (PRG) [START_REF] Goldreich | Foundation of Cryptography[END_REF] and a randomness extractor extract [START_REF] Barak | True Random Number Generators Secure in a Changing Environment[END_REF], where

-PRG is a stateless function G: {0, 1} m → {0, 1} 2m such that G(U m ) is com- putationally indistinguishable from U 2m
, where m is a security parameter and U m is the uniform distribution on {0, 1} m . -An extractor is a function extract(): {0, 1} n≥m × Λ → {0, 1} m for some index set Λ (according to Theorem 1). The output Ext(x, λ) is closed to the uniformly distributed, where x ∈ {0, 1} n is the output of the high-entropy source and λ ∈ Λ.

The BH robust pseudorandom generator

Given an extractor extract(): {0, 1} n≥m → {0, 1} m and a cryptographic non-robust PRG G: {0, 1} m → {0, 1} 2m , where m is a security parameter. By (r, s ) ← G(s), we denote that r is the first m bits in the output of G(s) and s is the last m bits and by G (s) =r, we denote a function G that on input s ∈ {0, 1} m outputs only the first m bits of G(s).

refresh(s, x), returns s ← G (s ⊕ extract(x)); next(s) returns (r, s ) ← G(s).

Definition of sustainable pseudorandom generator

We follow the BH paradigm that models an attacker on the generator in the real world as an efficient procedure A that has four interfaces to the generator, namely good-refresh(), bad-refresh(), set-state() and next-bits(). The ideal-world game proceeds similarly to the real-world game, except that the calls that A makes to its interfaces are handled differently.

The real-world game The real world game begins with the system player initializing the internal state of the generator to null, i.e., s = 0 m and then the attacker A interacts with the system using the following interfaces:

good-refresh(D) with D a distribution in H, called high entropy distributions. The system draws x ← R D, sets s = refresh(s, x) and updates the internal state to s . bad-refresh(x) with a bit string x. The system sets s = refresh(s, x) and updates the internal state to s . set-state(s') with an m-bit string s . The system returns to the attacker the current internal state s and then changes it to s . next-bits(). The system runs (r, s ) ← next(s), replaces the internal state s by s and returns to the attacker the m-bit string r.

The game continues in this fashion until the attacker decides to halt with some output in 0, 1. For a particular construction PRG = (next, refresh), we let P r[A(m, H) R(PRG) = 1] denote the probability that A outputs the bit 1 after interacting as above with the system that implements the generator PRG and with parameters m, H. Here R(PRG) stands for the real-world process from above.

The ideal-world game Formally, the ideal-world game is parametrized by the same security parameter m and family of distribution H as before. The game begins with the system player initializing s = 0 m and compromised =true and then the attacker interacts with the system using the following interfaces:

good-refresh(D) with D a distribution in H. The system resets compromised =false. bad-refresh(x) with a bit string x. If compromised = true then the system sets s = refresh(s, x) and updates the internal state to s . Otherwise (if compromised = false) it outputs a random string s ; set-state(s ) with an m-bit string s . If compromised = true then the system returns to the attacker the current internal state s, and if compromised = false then it chooses a new random string s ← R {0, 1} m and returns it to the attacker. Either way, the system also sets compromised = true and sets the new internal state to s . next-bits(). If compromised = true then the system runs (r, s ) = next(s), replaces the internal state s by s and returns to the attacker the m-bit string r. If compromised = false then the system chooses a new random string r ← R {0, 1} m and returns it to the attacker.

The game continues in this fashion until the attacker decides to halt with some output in {0, 1}. For a particular construction PRG = (next, refresh), we let I(PRG) denote the ideal process and let P r[A(m, H) I(PRG) = 1] denote the probability that A outputs the bit 1 after interacting as above with the system. Definition 2. We say that PRG = (next, refresh) is a sustainable pseudorandom generator (with respect to a family H of distributions) if for every probabilistic polynomial-time attacker algorithm A, the difference

P r[A(m, H) R(PRG) = 1] -P r[A(m, H) I(PRG) = 1]
is negligible in the security parameter l, m and n.

3 The proof of security Theorem 1. The Barak and Halevi's robust pseudorandom generator is sustainable assuming that the underlying algorithm G is a cryptographic pseudorandom generator and randomness extractor extract with respect to the family H that is statistically close to the uniform distribution of {0, 1} m . Proof. We consider the following experiments: Expr.R, an adversary A interacts with the real system; Expr.I, A interacts with the ideal process and Expr.H, a hybrid experiment which is defined below:

good-refresh(D) with D a distribution in high entropy resource H. The system draws d ← R {0, 1} m , sets s = G (d ⊕ s), and updates the internal states to s . The system resets compromised =false. bad-refresh(x) with a bit string x ∈ {0, 1} m . The system sets s ← refresh(s⊕ extract(x)) and updates the internal states to s . set-state(s ) with an m-bit string s . The system returns to the attacker the current internal state s. The system also sets compromised = true and sets the new internal state to s .

next-bits(s). The system runs (r, s ) = next(s) and replaces the internal state s by s and returns to the attacker the m-bit string r.

One checks to see that the only difference between Expr.R and Expr.H is the definition of the good-refresh(D), D ∈ H. From the construction of randomness extractor [START_REF] Barak | True Random Number Generators Secure in a Changing Environment[END_REF], we know that the output of randomness extractor is statistically close to U m . Also note that the output of good-refresh(D) with respect to high entropy source H is statistically close to U m . As a result, the output of good-refresh(D) defined in Expr.R and that defined in Expr.R are statistically close (statistical closeness is preserved by any function [START_REF] Goldreich | Foundation of Cryptography[END_REF]).

Next, we want to show that Expr.I and Expr.H are computationally close. Suppose that the view of A in Expr.I and that in Expr.H is distinguishable with non-negligible probability, we construct a challenger B such that given (r * , s * ), it can distinguish whether it is an output of G for a random s ← R {0, 1} m or they are chosen at random and independently from {0, 1} m with non-negligible property. The challenger B makes use of A as a subroutine and begins by choosing at random an index i * ← {1, . . . , q} and setting s ← 0 m and compromised = true. B's ith call of A is answered as follow Let q be a polynomial bounded on the total number of calls made by A to all of its interfaces. Consider the (q + 1) experiments H (i) , i = 0, 1, . . . , q, where in experiment H (i) , the first i calls of A to its interfaces are processed the way B processes queries for i < i * and the rest are processed the way B processes queries for i > i * . We claim that H (q) = Expr.I and H (0) = Expr.R. Let Pr[Dist(H (0) ) = 1] =δ 0 and Pr[Dist(H (q) ) = 1] =δ q |δ 0 -δ q | = |

≤ qε

This means that if the view of Expr.I and the view of Expr.R are distinguishable with non-negligible probability, then we are able to distinguish whether (r * , s * ) is an output of G for a random s ← R {0, 1} m or they are chosen at random and independently from {0, 1} m with non-negligible advantage.

Conclusion

In this paper, we have introduced and formalized the notion of sustainable pseudorandom generator which aims to fill the security gap between the ideal world and the real world in the BH robust pseudorandom generator. We have shown that the Barak and Halevi's construction is sustainable assuming that the underlying algorithm G is a cryptographic pseudorandom number generator and the output of the underlying randomness extractor is statistically close to the uniform distribution U m .

-

  good-refresh(D) with D a distribution in H. If i < i * , then the simulator chooses s ← R {0, 1} m at random. If i = i * , then the system sets s = s * , and if i > i * , then the simulator draws d ← R {0, 1} m , sets s = G (d ⊕ s), where s is the current internal state. Either way, the simulator updates the internal states to s and resets compromised =false.bad-refresh(x) with a bit string x. If compromised = true, the simulator sets s ← refresh(s⊕extract(x)). If compromised = false and i < i * , the simulator sets s ← {0, 1} m ; and if compromised = false and i = i * , then simulator sets s = s * and updates the internal states to s . If compromised = false and i > i * , the simulator sets s ← refresh(s ⊕ extract(x)). set-state(s ) with an m-bit string s . The simulator returns to the attacker A the current internal state s and sets compromised = true and the new internal state to s . next-bits(). If compromised = true or i > i * then the simulator set (r, s ) ← G(s). If compromised = false and i < i * then simulator chooses r, s ← {0, 1} m . If compromised = false and i = i * , then the simulator sets r = r * and s = s * . Either way, the simulator replaces the internal state s by s and returns to the attacker the m-bit string r.

  (H (i) ) = 1] -Pr[Dist(H (i-1) ) = 1]| ≤ q i=1 |Pr[Dist(H (i) ) = 1] -Pr[Dist(H (i-1) ) = 1]|