Docstoc

Application Requirements Document

Document Sample
Application Requirements Document Powered By Docstoc
					               Application Requirements Document




Academic Advisor:
                         Prof. Yuval Elovici

Professional Advisor:
                         Yuri Granovski

Team Members:            Shaul Mansour
                         Eldar Zilberman
                         Ohad Behore
                         Gilad Keinan



                                 1
                Application Requirements Document

                              Revision Control


Rev.   Detailed Description      Paragraph Reference   Approved by     Date

1.0      Original version                  -                         02/01/2010




                                       2
                              Application Requirements Document

                                                       Table of Contents
1.     Introduction ............................................................ Error! Bookmark not defined.4
     1.1.      Vision ........................................................................ Error! Bookmark not defined.4
     1.2.      The Problem Domain .............................................................................................4
     1.3.      Stakeholders .............................................................. Error! Bookmark not defined.5
     1.4       Software Context ...................................................................................................5
     1.5       System Interfaces ...................................................... Error! Bookmark not defined.6
       1.5.1 Hardware Interfaces.................................................................. Error! Bookmark not defined.6
       1.5.2 Software Interfaces ................................................................... Error! Bookmark not defined.6
       1.5.3 Events .................................................................................................................................... 7

2.     Functional Requirements .....................................................................................8
2.1 Component Requirements ...................................................................................9
2.1.1 GUI Requirements ............................................................................................9
2.1.2 Server Requirements ...................................................................................... 10
2.1.3 Authentication Module Requirements ............................................................ 10
2.1.4 Enabler Requirements .................................................................................... 12
3.Non Functional Requirements ................................................................................ 13
     3.1       Performance Constraints ...................................................................................... 13
       3.1.1       Speed .............................................................................................................................. 13
       3.1.2       Capacity .......................................................................................................................... 13
       3.1.3       Throughput ..................................................................................................................... 13
       3.1.4       Reliability ........................................................................................................................ 13
       3.1.5       Safety & Security ............................................................................................................. 13
       3.1.6       Portability & Reliability ................................................................................................... 14
       3.1.7       Usability .......................................................................................................................... 14
       3.1.8       Availability ...................................................................................................................... 14

     3.2       Platform Constraints ............................................................................................ 15
     3.3       SE Project Constraints .......................................................................................... 15
     3.4       Special Restrictions & limitations ......................................................................... 15
4      Usage Scenarios ................................................................................................ 16
     4.1       User Profile – The Actors ...................................................................................... 16
     4.2       Use-Cases ............................................................................................................ 17
     4.3       Special Usage Considerations ............................................................................... 29
5      Appendix ........................................................................................................... 30
     5.1       Glossary............................................................................................................... 30



                                                                           3
                   Application Requirements Document



1. Introduction
   1.1.        Vision
Today we are witnessing a great change in telecommunication technology when more
and more phone companies are changing their technology and choosing to use VoIP as
the new standard for telecommunication. This change is the cause for major security
problems which must be taken into consideration.

The goal of our project is to solve one of those security problems, supplying a way for
VoIP users to authenticate each other and make authenticated calls.
Our solution is based on public key infrastructure and will use public key certificates
issued by a central certificate authority (CA).

1.2.           The Problem Domain
The certificate authority will consist of:
        CA tools – certification creation and management.
        CRL - holding a list of revoked certificates, and will respond to queries.
        Communication service – service for client connections.
        Storage module – will save all issued certificates and client information.

The VoIP client will consist of:
        SIP agent - in charge of actual communication.
        Authentication module – exchanging certificates with other clients.
        Enabler – creation and management of public key certificates.
        Storage module – local database for each client.

Every VoIP client will be based on a different remote computer and will be able of
making calls to all known clients (omitting the need for SIP server).The receiving side will
decide whether a certain call will be authenticated or not, for authenticated calls
certificates will be swapped and challenges will be sent to authenticate certificate
holder's identity. At the first authenticated call, the client will communicate the CA,
sending a certificate signing request (CSR) and receiving a signed certificate to present
to other clients.

The authentication process will take part in few steps:
   1. Checking the certificates with the CA public key(CA trusted).
   2. Checking for expired certificate.
   3. Checking certificate holder's Id using a challenge.
   4. Checking the CRL for revoked certificates.



                                             4
                   Application Requirements Document

Connection between the VoIP clients and the CA will be based on TCP/IP. Actual VoIP
communication will be based on SIP.


1.3.    Stakeholders
VoIP authentication will offer a security solution that is useful for telephony service
providers. It will offer a solution to common IP based security issues, and will enable a
much higher level of call authentication. Our system will simulate a control model for
system service providers.

• Users - the users of the system will enjoy a secured system for making authenticated
calls that will require only minimal user interaction.
• Customers – our project is developed for Motorola Inc. in accordance to their
requirements and monthly reviews.



1.4. Software Context

   1.4.1. VoIP client will be a software application for installation on Linux OS. On first
          use our system will receive a "secret key" (received on installation).
          Once the client will make a call some of the next operations will take place:
           Initiate a call to a different client
           Creating a pair of public and private keys.
           Sending a CSR to the CA.
           Installing a signed certificate on local machine.
           Start authentication against remote client.



   1.4.2. CA server will be a remote application. The server will hold a database of all
          subscribers' personal information and a preliminary key.it will also be
          available for updates of new subscribers or a revocation of current
          subscribers.
          The server will offer the following functions:
               Issuing a new certificate.
               Answering a CRL query.
               Adding new subscribers.




                                             5
                 Application Requirements Document



1.5. System Interfaces

      1.5.1 Hardware Interfaces - our system does not interact with any hardware
      interface or other systems.

      1.5.2 Software interfaces - The system will use the Internet for
      communication between the clients and Server (via web services). In
      addition it will communicate within the system modules using TCP
      connection. The system will use SIP trough Sofia-SIP client interface.

      The communication of the different VoIP client components and the CA
      server components will be using the following interfaces:
      -CRL interface will support query and update
             Operation: CRL Query
             Used By: Authentication module.
             Parameters:
                     - Certificate ID a serial number for a given certificate.
             Return Values:
                 Valid the date of expiration of given certificate.

             Operation: CRL Update
             Used By: server GUI
             Parameters:
                    - Certificate ID a serial number for a given certificate.
                    - Description a short reason for certificate revocation.
             Return Values:
                    o none

      -CA tools interface will support certificate creation
             Operation: accept CSR
             Used By: Enabler.
             Parameters:
                     - Client all client personal data.
                     - Public Key the public key created by the enabler.
             Return Values:
                 Certificate a certificate signed by the CA.




                                             6
                  Application Requirements Document



       - CA database interface will support Adding of new subscribers
              Operation: Add Subscriber
              Used By: server GUI
              Parameters:
                     - Client all client personal data.
                     - Symmetric Key the preliminary key decided at client installation.
              Return Values:
                     None

1.5.3 Events
       The system will be driven by the following events:
           Adding new subscriber.
           Revocation of certificate.
           Sending of CSR.
           CRL query.
           Making a call.
           User configuration change.




                                            7
                 Application Requirements Document



2. Functional Requirements


  #      Functional Req.                         Description


[R1]    Versatility        The system shall support both authenticated and
                           unauthenticated calls.

[R2]    One point of       The system shall update the CRL only through the
        access             GUI.

[R3]    Automation         The system shall automate his services by zero touch
                           certification creation and installation.

[R4]    Usage of known     The system shall provide PKI management according to the
        standards          RFC 5280.

[R5]    Secured access     The system shall require a user name and password
                           for changing basic configuration in the GUI
                           component (at the CA server side).

[R6]    Calls monitoring   The system shall handle a log for all authenticated
                           calls.

[R7]    Certifications     The system shall handle a database for storing all the
        monitoring         certificates.

[R8]    Client             The system shall hold a list of the preliminary keys and
        authentication     their corresponding client identities. For
                           authenticating a certain client according to a given
                           message.

[R9]    Optional           The system shall allow for enabling/disabling the
        Authentication     authentication process.

[R10]   Usage of known     The system shall be based upon IETF x 509 standards
        standards          for Public Key Infrastructure.




                                        8
                   Application Requirements Document

  2.1 Component Requirements

        2.1.1 GUI Requirements

 #        Functional                              Description
            Req.

[R11]    Pleasant       The GUI shall be implemented by Flex.
         data display
[R12]    Unified        The GUI shall be in English.
         language

[R13]    Revoking       The GUI shall support revoking existing certificates.
         certificates

[R14]    Specified   The GUI shall be available in Linux.
         environment

[R15]    Monitor        The GUI shall require inserting a reason for revoking a
         revoke         certificate.
         operations

[R16]    Secured        The GUI shall be accessible only with administrator access
         access         right.




                                            9
                  Application Requirements Document

        2.1.2 Server Requirements



  #       Functional                              Description
            Req.

[R17]    Server         The Server shall be updated upon request from the GUI.
         Update

[R18]    Server         The Server shall manage a log file that will indicate who
         sessions       contacted the server, when the connection occurred and if his
         monitoring     request was approved.

[R19]    Secured     The Server shall secure his private key.
         sensitive
         information

[R20]    CSR            The Server shall store the CSRs it receives containing the
         monitoring     following details: Full name, City, Country, Email, Address,
                        Public key.




        2.1.3 Authentication Module Requirements


  #        Functional                                Description
             Req.

[R21]    Two sided         The authenticator shall initiate a challenge protocol to
         authentication    authenticate other clients identity. The challenge protocol
                           (two sided authentication) stages for client A and client B :

                              Client A randomize a secret number X, encrypt it with B's
                               public key and send the encrypted number X to Client B.

                              Client B decrypt A's secret number X, randomize his own



                                            10
                Application Requirements Document

                             secret number Y, encrypt both numbers with A's public
                             key and send it back to client A.

                             Client A decrypt the message, if his random number X is
                             right then B is authenticated, then he encrypt B's random
                             number Y with B's public key and sends it back to him.

                            Client B decrypt the message, if the receives his own
                             secret number Y the A is authenticated.

[R22]   PKI              The authenticator shall authenticate using PKI authentication
        authentication   identity validation procedure.

[R23]   CRL              The authenticator shall communicate with the server to
        enforcement      check if the certificate isn't revoked according to the CRL.

[R24]   Call             The authenticator shall not initiate a call if authentication of
        prevention       the other client's certificate has failed.

[R25]   Optional       The authenticator shall decide upon pre-configured settings
        Authentication weather to ask for authentication or not upon session
                       initialization with another client.

[R26]   Possession of    The authenticator shall store the certificate in DB (if the
        Certificate      Enabler received it from the CA Server) and will supply it in a
                         session when another client's creator has come up with such
                         request.




                                          11
                  Application Requirements Document

        2.1.4 Enabler Requirements


  #      Functional Req.                           Description


[R27]    CSR creation      The Enabler shall be responsible of CSR creation, on the
                           client side.

[R28]    Key generation    The Enabler shall be responsible of key generation at the
                           client side.

[R29]    SIP Client        The Enabler shall extend the SIP Client available services.
         abilities

[R30]    Communication The Enabler shall hold the CA IP address in order to be
         with the CA   able to initiate a sessions with the CA server.
[R31]    CA public key     The Enabler shall hold the public key of the CA server
         possession        after the first communication session with the CA server,
                           in order to avoid multiple communication sessions just to
                           get hold of the CA Server Public key for every
                           authentication of other clients.

[R32]    Server            The Enabler shall encrypt the CSR using preliminary key.
         authentication


[R33]    Stored personal The Enabler shall store the CSR containing the following
         info            details : Full name , City , Country, Email, Address , Public
                         key

[R34]    Certificates      The Enabler shall manage a log file that will indicate when
         operation         a CSR request was initiated, when certificate was
         monitoring        received, who requested it and when.




                                           12
             Application Requirements Document

3.Non Functional Requirements

   3.1 Performance Constraints

       3.1.1 Speed
             a) Processing a certificate signing request with the CA server
                should take less than 5 seconds.
             b) Exchanging certificates (sending and receiving a certificate)
                with another client should not take more than 1 second.
             c) Waiting for certificate authentication from the CA server
                should take less than 1 second.
             d) Detecting a non-authenticated client should not take more
                than 6 seconds.


       3.1.2 Capacity
             a) A client cannot initiate a call with more than 1 client.
             b) The system will not support conducting more than one call at
                a time (a client cannot initiate 2 calls at the same time).
             c) The number of users that can access the CA server
                simultaneously will not exceed 999(TCP/IP capabilities).
             d) The number of active users can the CA server can handle will
                not exceed 999(depends also on DB capabilities,
                approximately 50Kb per user)

       3.1.3 Throughput
             a) The CA Server should handle as many as 150 requests
                simultaneously.


       3.1.4 Reliability
             a) In 100% of cases when a client with a false certificate is
                authenticated with another client, the call attempt fails.
             b) In 100% of the cases when a client with a revoked certificate is
                required to authenticate his certificate with another client upon
                call initiation, the call attempt fails.


       3.1.5 Safety & Security
             a) Confidentiality is not a constraint in our system apart from
                sending CSR which is encrypted with a symmetric key, and a


                                     13
      Application Requirements Document

          challenge request which sends an encrypted number with the
          caller's public key. The communication between 2 parties is not
          encrypted.

      b) Only the operator can see and update which the condition of
         users in the system.
         This means that the operator can see about a certain user
         whether he/she has a revoked certificate or not, and whether or
         not his certificate has expired.
         Moreover, only the operator has the authority to revoke a user's
         certificate and or issue a new certificate to a user. Other users in
         the system do not have this ability, nor can they see this
         information.


3.1.6 Portability & Reliability
      a) The system works on Linux OS only. The system does not have a
         web - service, it has an application that is designated to its use.
      b) In case of a network failure any connection between client and
         server or 2 clients will be disconnected.
      c) In case of hardware or software failure the system on the client
         side is not
      d) When the server crashes whether it is its software crashing or its
         hardware crashing it is supposed to go back up restoring above
         90% of the data it previously acquired.


3.1.7 Usability
      a) The client's GUI should be simple to manage for the common user
         because it shall be limited in the number of options a client can
         perform (2 options).
      b) The client should be apparent when the agent is running and
         when there are errors but not overwhelm the user with
         redundant messages.
      c) The client GUI should be user friendly because of its simplicity
         there will be 2 options:
            1. Whether the client wishes to authenticate.
            2. To whom the client wishes to call.


3.1.8 Availability
      a) On the client side the system can be shut down and the client
         decides when to turn the system on in order to receive and


                               14
            Application Requirements Document

               initiate calls. When the system is operating it should run
               constantly regardless of any amount of applications running on
               the computer concurrently.
            b) On the server side the system should be up and running at all
               times in order to accept client request and send answers. The
               system should run constantly regardless of any amount of
               applications running on the server concurrently.




3.2 Platform Constraints

    The VoIP agent will be developed for Linux platform.
    The CA Server will be developed for Linux platform.
    The communication will be developed in C++ language.
    The GUI will be developed in Flex language.
    The logic of the system will be developed in JAVA.


3.3 SE Project Constraints
 The system is part of the whole software there isn't integration with the SIP
 Server.

 The system is semi-interactive, it means that the client can decide whether to
 authenticate the call or not.

 The input for the system is a secret number for every new client.

 For the demo the client knows the IP of another client to communicate.

 For the demo we use computer to simulate a server, and two computers
 simulating two clients communicating.



3.4 Special Restrictions & limitations

None




                                     15
                Application Requirements Document


4 Usage Scenarios

 4.1 User Profile – The Actors

   4.1.1 The User
   The User is responsible for starting a call and receiving one, and configuring the
   type of the call whether it be authenticate or not.

   4.1.2 The Operator
   The operator responsible to the operations on the CA server, he is capable of
   modifying Client's information in the DB, updating the CRL and getting statistics
   information from the server.

   4.1.3 The Installer
   The Installer Responsible for storing the user's information in the DB.
   This initial information includes symmetric key as secret, the server public key and
   basic information about the user.




                                         16
             Application Requirements Document



4.2   Use-Cases




                            17
                   Application Requirements Document



ID: 1
Primary actors: User
Description: The user enters the VoIP Client GUI and modifying his settings.
Trigger: The user decides to modify his settings.
Pre-conditions: The VoIP client is installed on the user's device.
Post-conditions: The new modified information has been saved in the DB.
Flow of events:
1. The user enters the VoIP Client GUI.
2. The user enters the settings screen and in there chooses to modify the setting
3. The user enters the new information and the system saves the information in the DB.

Alternative flows: none.
Covered Requirements: R11 – R16
Sequence Diagram:




                                              18
                    Application Requirements Document

ID: 2
Primary actors: system operator
Description: The system operator enters the registration information (ID, first name, last name,
address, symmetric key, etc') into the CA server’s GUI
Trigger: a new user subscribe to the service.
Pre-conditions: the CA server is installed and running and the operator is authorized.
Post-conditions: The registration information has been saved for further use, and creation of a
certificate later on. The symmetric key is sent to the installer.
Flow of events:
1. The system operator enters the CA server GUI.
2. The system operator enters a username and password for authentication.
3. The system operator enters the information (ID, first name, last name, address, symmetric
key, etc.) through the GUI and it is saved in the server database.

Alternative flows: login failure can occur if an unauthorized operator tries to update system.
Covered Requirements: R5, R8, R16, R17




                                               19
                    Application Requirements Document



ID: 3
Primary actors: system operator
Description: The system operator updates user certificate information (revocation or extension).
Trigger: a user subscription is expired or a user agreement violation has occurred.
Pre-conditions: the CA server is installed and running.
Post-conditions: the CRL is updated.
Flow of events:
1. The system operator enters the CA server GUI.
2. The system operator enters a username and password for authentication.
3. The system operator enters the information (user information, new expiry date).

Alternative flows: login failure can occur if an unauthorized operator tries to update system.
Covered Requirements: R2, R5, R13, R15, R16
Sequence Diagram:




                                               20
                    Application Requirements Document


ID: 4
Primary actors: system operator
Description: The system operator display a log of all recent system activities
Trigger: a weekly system review (time trigger) or by operator request.
Pre-conditions: the CA server is installed and running.
Post-conditions: a system log is presented.
Flow of events:
1. The system operator enters the CA server GUI.
2. The system operator enters a username and password for authentication.
3. The system operator asks for a time frame to review system actions.

Alternative flows: login failure can occur if an unauthorized operator tries to update system.
Covered Requirements: R5, R7, R16, R17, R18, R20
Sequence Diagram:




                                                21
                  Application Requirements Document

ID: 5
Primary actors: Installer
Description: The Installer enters the registration information (i.e. username, password
and Control Center URL) into the agent’s GUI
Trigger: The user decides to enter the registration info
Pre-conditions: The agent is installed on the device and is not currently running
Post-conditions: The registration information has been saved for future registration
with the Control Center
Flow of events:
1. The user enters the agent console
2. The user enters the settings screen and in there chooses to modify the settings
3. The user enters the username, password, Control Center URL and the agent saves the
information

Alternative flows: None
Covered Requirements: R5
Sequence Diagram:




                                          22
                     Application Requirements Document

ID: 6
Primary actors: The user
Description: The user initiates a call to another user on the network.
Trigger: The user enters a number to dial, and presses "send" button.
Pre-conditions: The VoIP client is installed on the device and is currently running.
Post-conditions: The user is communicating with another user
Flow of events:
    1. The user enters the VoIP client GUI.
    2. The user dials a number and clicks the "send" button.
    3. The Authenticator checks for a certificate at the DB on the client's side.
    4. The Authenticator calls the Enabler.
    5. The Enabler sends a CSR request to the CA server.
    6. The Enabler receives an authenticated certificate from the CA server.
    7. The Authenticator asks the other VoIP client's Authenticator to send him a signed
        certificate.
    8. The Authenticator gets a certificate from the other VoIP client's Authenticator.
    9. The Authenticator gets a certificate request from the other VoIP client's Authenticator.
    10. The Authenticator sends a certificate query to the CA server.
    11. The Authenticator receives a positive confirmation from the CA server.
    12. A challenge is being made between both VoIP client authenticators, and is successful.
    13. The SIP agent connects to the other client's SIP agent, and the call is established.

Alternative flows:
3 .a. Case: The Authenticator finds a valid certificate in the DB on the client's side.
Action:
- Continue to step 7

3 .b. Case: The Authenticator finds an expired certificate in the DB on the client's side.
Action:
- Continue to step 4

3 .c. Case: No authentication is required.
Action:
- continue to step 13.


5 .a. Case: communication to the CA server fails.
Action:
- An error will be displayed
- The VoIP client will return to main screen, and to its initial state.

6 .a. Case: The Enabler receives a negative answer from the CA server.
Action:
- An error will be displayed



                                                  23
                     Application Requirements Document

- The VoIP client will return to main screen, and to its initial state.

7 .a. Case: communication between the 2 VoIP clients fails
Action:
- An error will be displayed
- The VoIP client will return to main screen, and to its initial state.

11 .a. Case: The authenticator receives a negative confirmation from the CA server
Action:
- An error will be displayed
- The VoIP client will return to main screen, and to its initial state.

12 .a. Case: A challenge is being made between both VoIP client Authenticators, and one of the
Authenticators fails the challenge.
Action:
- An error will be displayed
- The VoIP client will return to main screen, and to its initial state.

Covered Requirements: R1,R21,R22,R23,R24,R25,R26,R27,R28,R30,R31,R33,R34
Sequence Diagram:




                                                  24
Application Requirements Document




               25
Application Requirements Document




               26
                     Application Requirements Document

ID: 7
Primary actors: The user
Description: The user receives a call from another user on the network.
Trigger: The user clicks "send" button to answer.
Pre-conditions: The VoIP client is installed on the device and is currently running.
Post-conditions: The user is communicating with another user
Flow of events:
1. The user enters the VoIP client GUI.
2. The user clicks the "send" button.
3. The Authenticator checks for a certificate at the DB on the client's side.
4. The Authenticator calls the Enabler.
5. The Enabler sends a CSR request to the CA server.
6. The Enabler receives an authenticated certificate from the CA server.
7. The Authenticator gets a certificate request from the other VoIP client's Authenticator.
8. The Authenticator asks the other VoIP client's Authenticator to send him a signed certificate.
9. The Authenticator gets a certificate from the other VoIP client's Authenticator.
10. The Authenticator sends a certificate query to the CA server.
11. The Authenticator receives a positive confirmation from the CA server.
12. A challenge is being made between both VoIP client Authenticators , and is successful.
13. The SIP agent connects to the other client's SIP agent, and the call is established.




Alternative flows:
3 .a. Case: The Authenticator finds a valid certificate in the DB on the client's side.
Action:
- Continue to step 7

3 .b. Case: The Authenticator finds an expired certificate in the DB on the client's side.
Action:
- Continue to step 4

3 .c. Case: No authentication is required.
Action:
- continue to step 13.


5 .a. Case: communication to the CA server fails.
Action:
- An error will be displayed
- The VoIP client will return to main screen, and to its initial state.

6 .a. Case: The Enabler receives a negative answer from the CA server.
Action:


                                                  27
                     Application Requirements Document

- An error will be displayed
- The VoIP client will return to main screen, and to its initial state.

11 .a. Case: The authenticator receives a negative confirmation from the CA server
Action:
- An error will be displayed
- The VoIP client will return to main screen, and to its initial state.

12 .a. Case: A challenge is being made between both VoIP client Authenticators, and one of the
Authenticators fails the challenge.
Action:
- An error will be displayed
- The VoIP client will return to main screen, and to its initial state.

Covered Requirements: R1,R21,R22,R23,R24,R25,R26,R27,R28,R30,R31,R33,R34
Sequence Diagram:




                                                  28
           Application Requirements Document




4.3 Special Usage Considerations
  Not applicable



                               29
                    Application Requirements Document

5 Appendix

    5.1 Glossary

    An application programming interface (API) is an interface implemented by a
     software program to enable interaction with other software, much in the same way
     that a user interface facilitates interaction between humans and computers. APIs are
     implemented by applications, libraries and operating systems to determine the
     vocabulary and calling conventions the programmer should employ to use their
     services. It may include specifications for routines, data structures, object classes
     and protocols used to communicate between the consumer and implementer of the
     API.

    Authentication is the act of establishing or confirming something (or someone) as
     authentic, that is, that claims made by or about the subject are true .This might
     involve confirming the identity of a person, tracing the origins of an artifact, or
     assuring that a computer program is a trusted one.

    A certificate is an official document affirming some fact. For example, a birth
     certificate or death certificate testifies to basic facts regarding a person's birth or
     death. A certificate may also certify that a person has received specific education or
     has passed a test or series of tests depending on the certification.

    Certificate authority or certification authority (CA) is an entity that issues digital
     certificates for use by other parties. It is an example of a trusted third party. CA's
     are characteristic of many public key infrastructure (PKI) schemes.

    Certificate Installation (or setup) of a certificate (including id, personal info, etc.) Is
     the act of putting the certificate onto a phone system so that it can be used for
     authentication

    Challenge – a series of actions designated to authenticate the calling entity against
     the data he has provided. In our project it means to send the caller a random
     number encrypted with his public key, and have him send back the same number
     encrypted in our public key.

    Client/VoIP client - It means a subsystem which enables communicating a user with
     another user, who uses another client, through the Internet.




                                               30
                    Application Requirements Document

   CRL - In the operation of some cryptosystems, usually public key infrastructures
    (PKIs), a certificate revocation list (CRL) is a list of certificates (or more specifically, a
    list of serial numbers for certificates) that have been revoked or are no longer valid,
    and therefore should not be relied upon.

   CSR - In public key infrastructure systems, a certificate signing request (also CSR or
    certification request) is a message sent from an applicant to a certificate authority in
    order to apply for a digital identity certificate. Before creating a CSR, the applicant
    first generates a key pair, keeping the private key secret. The CSR contains
    information identifying the applicant (such as a distinguished name in the case of an
    X.509 certificate), and the public key chosen by the applicant. The corresponding
    private key is not included in the CSR, but is used to digitally sign the entire request.
    The CSR may be accompanied by other credentials or proofs of identity required by
    the certificate authority, and the certificate authority may contact the applicant for
    further information.

   Enabler - a software module responsible for generating a pair of private and public
    keys, creating certificate signing request (CSR), and installing the given certificate at
    the client side.
   Encryption is the process of transforming information (referred to as plaintext) using
    an algorithm (called cipher) to make it unreadable to anyone except those
    possessing special knowledge, usually referred to as a key. The result of the process
    is encrypted information (in cryptography, referred to as cipher text). In many
    contexts, the word encryption also implicitly refers to the reverse process,
    decryption (e.g. “software for encryption” can typically also perform decryption), to
    make the encrypted information readable again (i.e. to make it unencrypted).

   A graphical user interface (GUI) is a type of user interface item that allows people to
    interact with programs in more ways than typing such as computers; hand-held
    devices such as MP3 Players, Portable Media Players or Gaming devices; household
    appliances and office equipment with images rather than text commands. A GUI
    offers graphical icons, and visual indicators, as opposed to text-based interfaces,
    typed command labels or text navigation to fully represent the information and
    actions available to a user. The actions are usually performed through direct
    manipulation of the graphical elements.

   Modular programming is a software design technique that increases the extent to
    which software is composed from separate parts, called modules. Conceptually,
    modules represent a separation of concerns, and improve maintainability by



                                               31
                   Application Requirements Document

    enforcing logical boundaries between components. Modules are typically
    incorporated into the program through interfaces. A module interface expresses the
    elements that are provided and required by the module. The elements defined in
    the interface are detectable by other modules. The implementation contains the
    working code that corresponds to the elements declared in the interface.

   PKI – The Public Key Infrastructure is a set of hardware, software, people, policies,
    and procedures needed to create, manage, distribute, use, store, and revoke digital
    certificates.

   Public-key cryptography is a relatively new cryptographic approach whose
    distinguishing characteristic is the use of asymmetric key algorithms instead of or in
    addition to symmetric key algorithms. Unlike symmetric key algorithms, it does not
    require a secure initial exchange of one or more secret keys to both sender and
    receiver. The asymmetric key algorithms are used to create a mathematically related
    key pair: a secret private key and a published public key. Use of these keys allows
    protection of the authenticity of a message by creating a digital signature of a
    message using the private key, which can be verified using the public key. It also
    allows protection of the confidentiality and integrity of a message, by public key
    encryption, encrypting the message using the public key, which can only be
    decrypted using the private key.

   In cryptography, a public key certificate (also known as a digital certificate or
    identity certificate) is an electronic document which uses a digital signature to bind
    together a public key with an identity — information such as the name of a person
    or an organization, their address, and so forth. The certificate can be used to verify
    that a public key belongs to an individual.

   SIP - The Session Initiation Protocol (SIP) is a signaling protocol, widely used for
    controlling multimedia communication sessions such as voice and video calls over
    Internet Protocol (IP). The protocol can be used for creating, modifying and
    terminating two-party (unicast) or multiparty (multicast) sessions consisting of one
    or several media streams. The modification can involve changing addresses or ports,
    inviting more participants, adding or deleting media streams, etc. Other feasible
    application examples include video conferencing, streaming multimedia distribution,
    instant messaging, presence information and online games.

   The subscription business model is a business model where a customer must pay a
    subscription price to have access to the product/service. The model was pioneered
    by magazines and newspapers, but is now used by many businesses and websites.


                                            32
                   Application Requirements Document

    Rather than selling products individually, a subscription sells periodic (monthly or
    yearly or seasonal) use or access to a product or service, or, in the case of such non-
    profit organizations as opera companies or symphony orchestras, it sells tickets to
    the entire run of five to fifteen scheduled performances for an entire season.

   User/End User – any person who is using a VoIP client.

   VoIP – Voice over Internet Protocol is a general term for a family of transmission
    technologies for delivery of voice communications over IP networks such as the
    Internet or other packet-switched networks. Other terms frequently encountered
    and synonymous with VoIP are IP telephony, Internet telephony, and voice over
    broadband (VoBB), broadband telephony, and broadband phone.

   Zero touch certification creation and installation – it means that the installation of
    certificates by the system will be done automatically.




                                            33

				
DOCUMENT INFO