DOC

KRYPTO Design Document

By Eddie Walker,2014-04-14 03:36
9 views 0
by P Huy - Related articles

    Carnegie Mellon University CMU-MSE-KRYPTO-DD1.0 School of Computer Science Spring 2001 Master of Software Engineering

     Krypto Team

    Design Document

    Version 1.0

    May 3, 2001

    Pisey Huy

    Grace Lewis

    Ming-hsun Liu

CMU-MSE-ZEPHYR-ARCH-HLD-1.0

Table of Contents

    Table of Contents .......................................................................................................................................... 1 List of Figures ............................................................................................................................................... 3 1 Acronyms ............................................................................................................................................. 1 2 Introduction .......................................................................................................................................... 2 2.1 Purpose ........................................................................................................................................ 2 2.2 Scope ........................................................................................................................................... 2 2.3 Overview ..................................................................................................................................... 2 3 Architecture .......................................................................................................................................... 4 3.1 Critical Design Criteria ................................................................................................................ 4

    3.1.1 Functionality ........................................................................................................................... 4

    3.1.2 Extensibility ............................................................................................................................ 5

    3.1.3 Portability .............................................................................................................................. 10

    3.1.4 Performance .......................................................................................................................... 10

    3.1.5 Security ................................................................................................................................. 10 3.2 Architectural Style ..................................................................................................................... 11 3.3 Architectural Views ................................................................................................................... 11 4 NDBS 2.0 High-Level Design ........................................................................................................... 15 4.1 Keystore Management Layers ................................................................................................... 15 4.2 Netscape KeyStore Layer .......................................................................................................... 17 4.3 Netscape Crypto Façade Layer .................................................................................................. 19 4.4 Netscape Storage Manager Layer .............................................................................................. 20 References ................................................................................................................................................... 22 Appendix Detailed Design ....................................................................................................................... 23

CMU-MSE-ZEPHYR-ARCH-HLD-1.0

CMU-MSE-ZEPHYR-ARCH-HLD-1.0

List of Figures

    Figure 1. Bridge Pattern in NDBS 2.0 ...................................................................................................... 6 Figure 2. Code in NDBSKeyStore.java that implements the Bridge Pattern ........................................... 6 Figure 3. Façade Pattern in NDBS 2.0 for HMAC SHA-1 ....................................................................... 8 Figure 4. Java sample code for implementing the Facade Pattern for the HMAC with SHA-1 algorithm

    in NDBS ............................................................................................................................................... 9 Figure 5. Java sample code for implementing the Facade Pattern for the HMAC with SHA-1 algorithm

    in NDBS (continued) .......................................................................................................................... 10 Figure 6. NDBS 2.0 Architecture ........................................................................................................... 12 Figure 7. Mapping of Components to the NDBS 2.0 Architecture......................................................... 13 Figure 8. Microsoft Security Architecture .............................................................................................. 14 Figure 9. UML Class Diagram for the Keystore Management Layers. .................................................. 16 Figure 10. UML Class Diagram for the Netscape KeyStore Management Layer .................................... 18 Figure 11. UML Class Diagram for the Netscape Crypto Façade Layer .................................................. 20 Figure 12. UML Class Diagram for the Storage Manager Layer ............................................................. 21

CMU-MSE-ZEPHYR-ARCH-HLD-1.0

1 Acronyms

    CMU Carnegie Mellon University

    CSP Cryptographic Service Provider

    DB Database

    MSE Master of Software Engineering

    NDBS Netscape Database Keystore

    SOW Statement Of Work

    SPMP Software Project Management Plan

    SRS Software Requirements Specification

CMU-MSE-ZEPHYR-ARCH-HLD-1.0 1

2 Introduction

    This document contains the Architecture and High-Level Design information for Netscape Database

    Keystore 2.0 (NDBS). During the 2000-2001 Master of Software Engineering (MSE) Studio, the Krypto

    Team will develop NDBS 2.0 for their customer, the Software Engineering Institute.

    Additional information about NDBS 2.0 and the Krypto Project can be found in the Krypto Statement of

    Work [1] and the Krypto Software Project Management Plan [3].

    2.1 Purpose

    The purpose of this document is to provide a description of the important structural entities of NDBS 2.0,

    and to provide the detailed design.

    The architecture portion of the document includes functional and non-functional qualities of the system

    (e.g. portability, extensibility, etc.) that are of an architecturally significant nature.

    The high-level design section emphasizes the structural aspects of the systems, as well as additional

    information about the organization of NDBS 2.0 and the rationale behind that organization.

    2.2 Scope

    The scope of this document covers the architectural, high-level design concerns, and the detailed design

    of NDBS 2.0 as developed by the Krypto Team during the 2000-2001 MSE Studio year. For information

    about the NDBS 2.0 functionality refer to the Krypto Software Requirements Specification [Z].

    2.3 Overview

    This section provides an overview of the remainder of this document.

    Section 1 introduces this document.

    Section 2 describes the NDBS 2.0 architecture and describes the critical design criteria.

    Section 3 presents the high-level design of NDBS 2.0.

    Appendix A contains the detailed design of NDBS 2.0, produced using the Rational Rose Documentation

    Report feature.

    CMU-MSE-ZEPHYR-ARCH-HLD-1.0 2

Appendix B contains the specification for each of the classes in NDBS 2.0, produced using the Rational

Rose Print Specifications feature.

CMU-MSE-ZEPHYR-ARCH-HLD-1.0 3

3 Architecture

    This section describes critical design criteria and presents several views of the NDBS 2.0 architecture. These criteria were identified due to their high priority for NDBS 2.0 stakeholders. A specific definition of each property in the context of NDBS 2.0 is provided.

    3.1 Critical Design Criteria

    In any design effort, the goal is to maximize the overall quality of the design and the resulting product. This is often difficult because many desirable quality attributes are in direct conflict with one another. Maximizing the quality of the system in one dimension requires diminishing the quality of the system in another. To deal with this problem, designers must have a clear understanding of which quality attributes are most important to the stakeholders of the system at the outset of the project. A prioritized list of those attributes should be used in selecting between design alternatives to maximize system quality along the most critical dimensions. This section lists the design criteria identified as highest priority for the NDBS 2.0 architects. For each quality attribute, a description is given of its specific meaning in the context of the Krypto Project. Criteria are listed in order of descending importance.

    3.1.1 Functionality

    Functionality defines the ability of a system to do the work for which it was intended. Performing a task requires that the system’s components work together to complete a job. Any number of possible structures can be conceived to implement any given functionality [5]. Following this definition, the functionality of NDBS 2.0 is described.

    NDBS 2.0 will provide the same functionality as NDBS 1.0. NDBS 2.0 will contain 100% Java code that implements the methods required by the abstract class java.security.KeyStoreSpi. This will

    require the conversion of the NDBS 1.0 C code, as well as the underlying Berkeley DB C API and encryption algorithms used by NDBS.

    NDBS 2.0 will also extract certificates and private key information from the Netscape databases (cert7.db and key3.db). NDBS 2.0 will fully support both password protected and password unprotected Netscape databases.

    The keys stored in the Netscape database are RSA keys. As such, NDBS 2.0 will follow NDBS 1.0 and rely upon JDK 1.2's KeyFactory class to generate RSA Private Keys in Java, thereby requiring access

    to a JCE 1.2 compliant provider for RSA. NDBS 1.0 has been developed and tested using JCE 1.2 compliant RSA providers from both RSA's product Crypto-J and Entrust's Java Tools. Therefore, any Java CMU-MSE-ZEPHYR-ARCH-HLD-1.0 4

application that wishes to use NDBS 2.0 must ensure that a default provider for RSA is installed or is

    established prior to calling any method provided. Otherwise, an exception will be raised.

    All the encryption algorithms in NDBS 1.0 are written in C code. NDBS 2.0 will provide the equivalent

    algorithms in 100% Java, using the Java Cryptography Extension (JCE).

    NDBS 2.0 functionality will be compared to that of NDBS 1.0 by performing the following tests:

    1. Comparing the output of each of the NDBS 1.0 functions with its equivalent NDBS 2.0 method

    written in 100% Java. Example outputs are results from functions, screen outputs, and file outputs. 2. Replacing NDBS 1.0 with NDBS 2.0 as the Java keystore service provider and running keytool, a

    Java key/certificate management tool. The output should be exactly the same. 3.1.2 Extensibility

    Extensibility defines the capacity of an existing system to support additional features. Although

    extensibility is not observable at runtime, it is important for the future life of a system.

    The following possible scenarios represent extensibility requirements in NDBS 2.0:

    ? Netscape upgrades the version of Berkeley DB used to store its keystore information. ? NDBS is extended to support Microsoft CryptoAPI keystores.

    ? The user can choose any crypto provider that is compliant with the Java Cryptography Extension

    (JCE) and provides algorithms for Triple DES with CBC, HMAC with SHA-1, and SHA-1. NDBS 2.0 provides extensibility features by using design patterns, specifically the Bridge Pattern and the Façade pattern [6].

    The purpose of the Bridge Pattern is to separate the interface of a class from its implementation, so that the implementation can be varied or replaced without changing the client code. The use of the Bridge

    Pattern in NDBS 2.0 is shown in Figure 1.

    CMU-MSE-ZEPHYR-ARCH-HLD-1.0 5

Report this document

For any questions or suggestions please email
cust-service@docsford.com