Classification as an approach to public key infrastructure requirements analysis

IET SoftwareVolume 13, Issue 6 p. 518-527 Research ArticleOpen Access Classification as an approach to public key infrastructure requirements analysis Radomir Prodanović, Corresponding Author Radomir Prodanović radomir.prodanovic@vs.rs Department for Telecommunications and Informatics (J-6) SAF GS, Centre for Applied Mathematics and Electronics, Serbian Armed Forces, Vojvode Stepe 445, 11000 Belgrade, SerbiaSearch for more papers by this authorIvan Vulić, Ivan Vulić Military Academy, University of Defence, Pavla Jurišića – Šturma 1, 11000 Belgrade, SerbiaSearch for more papers by this author Radomir Prodanović, Corresponding Author Radomir Prodanović radomir.prodanovic@vs.rs Department for Telecommunications and Informatics (J-6) SAF GS, Centre for Applied Mathematics and Electronics, Serbian Armed Forces, Vojvode Stepe 445, 11000 Belgrade, SerbiaSearch for more papers by this authorIvan Vulić, Ivan Vulić Military Academy, University of Defence, Pavla Jurišića – Šturma 1, 11000 Belgrade, SerbiaSearch for more papers by this author First published: 01 December 2019 https://doi.org/10.1049/iet-sen.2018.5286Citations: 1AboutSectionsPDF ToolsRequest permissionExport citationAdd to favoritesTrack citation ShareShare Give accessShare full text accessShare full-text accessPlease review our Terms and Conditions of Use and check box below to share full-text version of article.I have read and accept the Wiley Online Library Terms and Conditions of UseShareable LinkUse the link below to share a full-text version of this article with your friends and colleagues. Learn more.Copy URL Share a linkShare onFacebookTwitterLinkedInRedditWechat Abstract Classification schemes and taxonomy of request have focused only on business or software requirements defined by general non-functional requests. Public key infrastructure (PKI), as a complex system, requires special attention in the process of identification and definition of requests in all parts of the system. Requests efficiently identified and defined are the basis for successful PKI development and implementation. This study proposes a new classification scheme of requirements that enable effective identification of PKI requests in all system development life cycle phases. The proposed classification scheme has been designed in a way that can be used both by organisations just introducing a PKI system in their business operations, as well as organisations developing and implementing the PKI. Although there are more classification schemes and taxonomy of requests, the proposed classification scheme is the optimum solution for identification and definition of PKI system requests, as well as a good basis for testing, verification and validation of the PKI final product. 1 Introduction Understanding users' requirements are an integral part of information systems' design and represent a critical point in their successful realisation. Information system product lifetime starts with understanding users' requests and requirements. Many studies proved that errors made in defining requests lead to projects costing more and may lead to projects ultimately being rejected as unrewarding. According to IAG assessment [1], companies with poor practise of the definition of users' requirements spend 100% more per project than projected, while companies with good users' requests definition practise spending 21% more than budgeted. Requirement changes during project implementation negatively influence project budget, as well as requirements defined and realised but later not used by users. Errors made from poor elicitation of requests clearly cause significant problems which, in turn, lead to small as well as big projects crash. In 2006, Davis et al. [2] found that poorly defined system requests are the main cause of the crash of 90% of big software projects. According to [3], Souter [4] and van Lamsweerde [5], besides many techniques for business processes, requests and techniques for elicitation of requests analysis, there still exists a problem in requests elicitation and defining. This is mirrored in the insufficient overview of user's needs, poor elicitation of requests, unclear requests defining and defining of unnecessary requirements. Beside typical [6] situations that disrupt or in other way influence process of requests elicitation, Wiegers underlines the significance of having a requests elicitation domain, meaning that the existence of requirements classification scheme representing domain boundaries within organisation's managers and team for requirements elicitation and defining could work. PKI is a complex system that consists of hardware, software, people, policies and procedures necessary for the creation, management, distribution, use, PKI storage and revocation of electronic certificates and public key cryptography management. The prerequisite for successful PKI operation is the existence of well set and defined requirements, starting with business-information and fundamental PKI operating requirements, to requirements related to maintenance, training, transitional and future PKI development requirements. The proposed classification of PKI requirements provides such a classification which organisations developing and implementing PKI or requiring PKI might use to create requirement categories enabling faster and easier elicitation and defining of PKI requirements and preventing confusion. Section 2 of this paper provides a short description of already proposed classification schemes. In Section 3, authors conduct an analysis of the existing requirements classification schemes. The proposed PKI requirements classification scheme is given in Section 4. Section 5 describes the application and results of the proposed classification scheme, while the conclusion is summed up in Section 6. 2 Review of existing requirements classification schemes Boehm proposed a classification [7] which divides non-functional requirements on the first level on portability, usability and maintenance requirements. At its lowest level, this classification describes qualities that non-functional requirements should have. A maintenance requirement is related to a measure to which software is maintainable. Boehm's classification requirements are not sufficient enough for PKI development and maintenance because they are related only to non-functional requirements but the fact that this classification takes into account maintenance requirements influenced authors to take into consideration PKI maintenance requirements in their proposed classification scheme. Davis in [8] considers non-functional requirements as non-behaviour requirements and identifies seven qualities. Non-behaviour requirements define product quality and as such are a good foundation for ready product testing. Gilb [9] does not classify but define requirements considering the following categories: functions, qualities, costs and constraints. He defines requirements based on What system should do?; How well certain functionality should work?; and What is the cost of resources necessary for achieving functionality and its maintenance and requirements constraints? Division according to Sommerville on its first-level groups product requirements, organisational requirements (implementation, standards and delivery requirements) and exterior requirements as a non-functional requirement [10]. Product requirements are related to possible and desired characteristics of a system. As authors in this paper consider complete business PKI and not just PKI product, the proposed classification takes into account organisational requirements. Glinz [11] classified non-functional requirements as performance and quality of interconnected requirements which could be described by four aspects: type, representation, satisfaction and services. van Lamsweerde [12] classifies non-functional requirements according to the quality of service, compliance, architecture and development constraints. The classification scheme [13] describes non-functional requirements applied to service-oriented software and systems. This classification comprises requirements related to desired service characteristics, product development requirements, requirements related to legal framework and constraints as well as those requirements that present constraints of service architecture. Classification scheme functionality, operativeness, compliance, usability, security, time, budget, documentation, maintenance and support (FOCUS-TBD) [14] do not stop at non-functional requirements but take into consideration general functional requirements, safety, business regulations, legal framework and environment. This classification scheme takes into account more than just product requirements; it, also, considers requirements related to the system within which they will function. Acronym functionality, usability, reliability, performance and supportability [15] represents a model for classification of software quality properties, that is, for non-functional requirements classification. There are other classification schemes [16] based on interface, performance, operating, life cycle, political and economic requirements. One classification that encompasses not only product requirements but also requirements enabling implementation of the product within organisations' system is given in the business analysis body of knowledge (BABOK) Guide [3]. The classification scheme according to BABOK Guide contains the following requirements: business, stakeholder, product and transitional requirements. Shukla notes the following types of requirements [17]: business, user and system requirements. System requirements are divided into functional and non-functional requirements. Business requirements describe benefits for the organisation or its clients gained by the product introduction. User requirements describe users' needs related to the system operations, while system requirements define system operations themselves. Adams MacG [18] addresses the wide range of non-functional requirements and introduces a number of taxonomies that have been used to describe non-functional requirements. This taxonomy distributes 27 non-functional requirements into four concerns: sustainment concerns, design concerns, adaptation concerns and viability concerns. Classification scheme [19] introduces a new category of security requirements based on a combination of other proposed schemes. 3 Analysis of requirements classification schemes Division of requirements into functional and non-functional is too general to be used as a support in quality requirements elicitation and defining. Classification schemes defined in [5, 7, 13, 14, 16, 17] comprise, beside non-functional requirements, requirements related to maintenance, organisation and legal framework. These classification schemes cover to some extent requirements related to legislation and standard compliance, as well as product operation after implementation. Classification schemes defining product quality [8, 9, 11, 15, 18] are general and give good guidelines for testing and validating implemented products. Previously mentioned classification schemes are all related to general non-functional requirements. However, in order to assist management personnel to make the right decisions, as well as to help quality requirements elicitation and defining, it is necessary to specify a classification scheme for a certain product. These classification schemes give a good foundation for later testing of implemented products. 4 Proposed PKI classification scheme The proposed classification scheme was inspired by [3] and Comai [14] classifications, and, also, by PKI functional components. The classification scheme presented in this paper (see Fig. 1) is comprised of six main categories of requirements: Fig. 1Open in figure viewerPowerPoint Proposed PKI classification scheme Business–organisational requirements: Business requirements for PKI organisations must improve the protection level of business information in e-business. Organisational PKI requirements serve to prepare organisation, management and working staff for PKI through all stages of PKI system implementation. PKI components and services requirements: These requirements describe expected behaviour and attributes of a PKI, all in accordance with business requirements. They describe properties of PKI in terms of its exploitation, behaviour and implementation through actions and responses. Hardware–software requirements: Software product behaviour within PKI is described by software requirements. Standards and conditions that hardware must comply in order to enable safe implementation of PKI software are defined through hardware requirements. Security requirements: Security requirements define the security of the whole PKI and are defined in such manner that by their fulfilment, security properties of the whole PKI are achieved. Requirements for support in functioning: These requirements provide support for all PKI components and users. Support in functioning needs to be defined properly so that there are no delays in PKI service and components work caused by functional related reasons or user ignorance. Transitional requirements: These requirements arise in all phases of PKI requirements analysis. They provide additional qualities that may be overlooked during the requirements elicitation phase but are found later during PKI development phases. 4.1 Business–organisational requirements This type of requirements should enable planned PKI implementation within the business with optimal resource usage. These requirements should be defined in such a way that they do not cause a departure from established business goals, loss of reputation, partners, financial resources and staff. Business requirements: PKI business requirements should support and enable achievement of business goals through business information security in e-business. Security of business information provides additional quality to organisations in electronic business domain and advantage over their competitors. Business requirements are considered through the following subcategories: Requirements for management improvement: These requirements should determine which PKI functionalities assist in management improvements within the organisation but, also, management improvements in communications with other business subjects, as well as how much new functionalities implementation influences reorganisation. Requirements for security improvement: These determine which improvement through PKI implementation will raise the security level of business information and to what extent. Marketing requirements: Marketing requirements determine to what extent and in what way to present the new quality that the organisation has acquired through the introduction of PKI technology in order to gain a better position over the competition. Economy requirements: These types of requirements determines to what extent and in what way PKI implementation will be economical, as well as their influence on e-business strategy. Integration requirements: Integration requirement determines the way of conducting business both with organisations with different security policies and the ones with their own PKI. Education requirement: Education requirements determine the type of user to be educated and the content of education. Stakeholder requirements: This requirement defines a group of elements to be overviewed while making a choice regarding the PKI architecture provider. Organisational requirements: Organisational requirements should contribute to building a system supported by manager structure during all phases of PKI implementation. A good organisation should enable rational resource exploitation, good communication, safe project goal achievement, the building of motivated and positive work environment, improvement and development of new skills, preventing chaos and delay. Organisational PKI requirements are considered through the following subcategories: Preparation for PKI implementation requirement: Defines which activities are necessary for the organisation to prepare for timely PKI implementation. The requirement for organising workflow: Enables successful and optimal functioning of the staff with rational resource exploitation at the same time. The requirement for regulatory documents: Specifies which regulatory documents should be complied to during the introduction and functioning of PKI, as well as which persons have to follow certain regulatory documents. 4.2 Requirements for PKI services and components Requirements for PKI services and components should define desired PKI functionalities in all its parts. Requirements of this type are considered through the following subcategories: general PKI requirements, certificate requirements, certificate authority requirements, registration authority requirements, status services and directory requirements and user services requirements. These requirements specify the purpose of certain parts of the system: General PKI services and components requirements: These general requirements provide a broad picture of the demands of PKI services and components should satisfy. Every product is followed by requirements for compatibility, interoperability, simple development, user-oriented interface, flexibility, scalability and adaptability, and the same applies to the PKI product. Certificate requirements: Certificate structure requirements are divided into general and additional requirements, where general requirements apply to all certificate types. General requirements are derived from the purpose of certificate and its structure [20]. Additional requirements (e.g. certificate to be qualified) are related to the specificity of each class that arises from certificate security levels. Certificate authority requirements: Certificate authority requirements should be such that certificate authority can create certificates according to the previously defined certificate requirements, manage certificates and keys and other data necessary for it to properly function. Certificate authority requirements are considered through the following requirements subcategories: Certificate authority access control requirements: Provide limited certification system access. Certificate management requirements: Are one of the most significant certificate authority functionalities. Certificate management requirements should be considered through the certificate life cycle: initialisation, issuance (renewal), certificate distribution, suspension, revocation and certificate archive. Key management requirements: Define the procedure for suitable length key pair generation, with a suitable algorithm and according to defined profiles. Archive requirements: Determine which current and archived data are to be saved (e.g. data regarding users, certificate and keys), data integrity and privacy, data lifetime, access to data conditions, as well as to who has the access to it. Log requirements determine several types of logs: log's security level, content to be logged, events that cause log update and access control mechanism. Registration authority requirements: Registration authority implements user registration procedure and submits the request for certificate issuance. Requirements of this type are considered through the following subcategories: Number and type of registration authority requirement: Determines the necessary number of registration authorities, their type (external, internal, user or resource-related registration authority) and their geographic placement in order to cover the whole base of potential users. Registration procedure requirement: Enforces the process and method for user application, registration form defining, the time period needed for the registration process, the process of user data check, determining relevant data to be used in the registration authority application and data to be archived in the paper form. Application functionalities requirement: Determines the following functionalities of registration authority application: data from registration, logical data check, request for certificate issuance generation, suspension, activation and revocation of electronic certificate, monitoring of all activities enforced over the submitted user request, monitoring of issued electronic certificate and its carrier life cycle, user data change, data logging and data search over the various criteria. Events logging requirement: Determines which events in the registration authority work process should be logged. Status and directory services requirements: User services, application and services of other manufacturers who use certificates could require certificate status check. To enable certificate status check, it is necessary to provide status services. Status services provide answers about the certificate status, whether it is suspended or revoked. The following status services are to be considered: Certificate revocation list (CRL) service: Requirement for CRL service should provide CRL issuance in compliance with X.509 regulative, CRL structure in compliance with [20], method of its publication (hypertext transfer protocol, lightweight directory access protocol or some other way), CRL access control, additional distribution points, availability of CRL service and procedures for CRL archiving and protection. Online certificate status protocol (OCSP) service: OCSP service should be defined in compliance with the RFC 2560. Directory service publishes issued certificates and it is recommended that certificates to be published are the ones used for data encryption. While defining this type of requirement, it is necessary to determine which mandatory and recommended certificate services. Service requirements: These types of requirements determine service types within the PKI system. Basic service types in PKI are: Authentication requirements: Determine the type of authentication, authentication protocol, parameters for configuration of authentication channel, conditions for token usage, documenting the procedure and chosen protocol verification. Requirements for signing service: Determine in which standard format the electronic signature operation will result, the potential for software integration with other software and services, authorisation when using the private key, hash function and asymmetric signing algorithm according to ETSI TS 102 176–1 and form of signing display. Requirements for signature verification services: Determine integration with the software for electronic signing, that software solution is in compliance with [21], that document display is identical as it was at the time of signing, informing the user if the document contains any dynamic content and status of signature verification display. Time-stamping service requirement: This service should be defined according to ETSI TS 102 023 and defines interested parties that will use this service. 4.3 Security requirements These requirements should define PKI security through general security requirements, specific security requirements and cryptography requirements: General security requirements: General security requirements related to security requirements of the organisation's certificate authority and its software components that support certificate and registration authority functionalities. These requirements are considered through: Computer network security requirements: Determine network address scheme, security measures for communication devices, the need for external network connections, access list control, firewall type and configuration, methods and policy for remote access. System software security requirements: Determine appropriate software choice, installation of only tested software with the latest patches, enabling only necessary system services, configuring security parameters and choice of location with the network environment. Software components security requirement: Determine appropriate authentication mechanism, secure communication between components, appropriate access privileges, configuring security parameters and choice of secure archiving to the database. Certificate authority physical security requirements: Determine the following: physical protection of certificate authority's keys, certificate authority physical protection, location for safe storage of backup copies and heating, ventilation and air conditioning system. Requirements for the protection against malicious software: Disable the introduction of malicious software within certificate authority. Staff security requirements: Determine staff hiring criteria, security checks staff, defined employee responsibilities, staff security tasks, education from the information security domain and responsibilities during the security incidents and irregularities in processes. Specific security requirements: Specific security requirements for the certificate authority are related to security measures that certificate authority enforces in its running. Security measures are taken into consideration through the following security requirements: In the requirements for the certificate revocation and suspension policy, it is necessary to define conditions leading to the certificate revocation before the expiration of its validity [21]. The requirement for CRL security policy: Determines algorithm and key length used for CRL signing, type of authentication necessary for the CRL generation and publishing service, CRL generation time and validity and CRL archive. Hardware security module (HSM) security policy requirement: Determines protection of the HSM device against the unauthorised access, production of backup copies, shared roles, secure safekeeping keys backup and other token contents, distributed keeping of the protected content and resources for access to the protected content [22]. The requirement for software security during the developmental phase: Determines authentication and authorisation mechanisms to be implemented, security integration in all phases of software development [23]. Shared roles requirement: Defines different roles that employees could have, identification of tasks and activities where shared roles are necessary, documenting and role protection. Security monitoring requirement: Security events within certificate authority need to be monitored and logged. Cryptography requirements: Requirements for the cryptography should define algorithms and key length enabling reliable defence against cryptanalyst's attack. These are considered through the following requirements: Requirements for cryptographic algorithms: Determine which cryptographic algorithm will be used for key pair generation, hash function and algorithm for the protection of backup keys for certificate authority. Requirements for the cryptographic keys: In requirements for the cryptographic keys, it is necessary to define key pair length and effective key's lifetime for all certificate authorities and end users. Private keys protection requirement: This requirement should be taken into consideration through the protection of end-user's private key, certificate authority's private key and resource's private key. 4.4 Software–hardware requirements Software requirements: Software requirements should define system characteristics in order for PKI software components to be compatible with the existing software platforms, within an existing information system or with standard e-mail applications or browsers. Software requirements are considered through the following: Certificate owner software requirement: Defines platform on which certificate owner's software will run, the technology used for eID access, the necessity for integration with third-party software, configuring end-user devices, online and off-line works, software purpose and use licence. Certificate user's (recipient) software requirements: Should be able to receive and process certificates without any other resources that should be integrated into the existing system. Certificate authority software requirements: Define an interface for the configuring necessary security parameters, certificate configuration parameters, management of certificate authorities and monitoring services by system administrators. General PKI software requirements that should be defined are: performance, modularity, scalability, controllability, maintainability, usability, language support, availability, logging and configurability. Hardware requirements: Hardware requirements define resource characteristics that support the functioning of the PKI software. This mostly presumes hardware within the certificate authority only. Hardware requirements are considered through the following: General hardware requirements determine the functionality of a device, reliability of a device, mean time to repair, device accuracy, device performance, support or maintenance, access to documentation, compatibility and interoperability of device components, interfaces and ports, licence and standards. Server equipment requirements: Determine server load and ability to be upgraded with more hardware capacity. Requirements for cryptographic devices: Cryptographic devices should satisfy the following: they are in compliance with FIPS PUB 140–2 level 3 or higher, or in compliance with equivalent standards [24], to be able to generate projected number of keys without delay,