Upload
guifei-shi
View
314
Download
0
Tags:
Embed Size (px)
DESCRIPTION
FOR TEST
Citation preview
University of South AustraliaComputer Systems Engineering Project
Speaker Verification for Smart Cards
SDD - Software Design Description
Version 2.000005
July 28th, 1998
Project Group: Cecilia Berry 9506009uGlen Olafsen 9505995dPeter Smith 9506003n
Project Supervisors: Arek Dadej (PES)Chris Steketee (CIS)
Software Design Description
Preface
The Software Design Description documentation encapsulates all of the designs at both system level and sub-system level, which produces a system, which meets all of the requirements identified in the SRS. As such the SRS is the most important piece of reference material used in the production of the SDD. The designs contained in this document enable the project team to build the system quickly, with lower rates of error and with higher quality.
Speaker Verification for Smart Cards 2
Software Design Description
Table of Contents
1 INTRODUCTION.............................................................................................................................5
1.1 PURPOSE.....................................................................................................................................51.2 SCOPE.........................................................................................................................................51.3 DEFINITIONS AND ACRONYMS...................................................................................................61.4 REFERENCES...............................................................................................................................7
2 DECOMPOSITION DESCRIPTION............................................................................................8
2.1 SYSTEM ENTITIES.....................................................................................................................112.1.1 Smart Card Operations....................................................................................................112.1.2 Smart Card Data..............................................................................................................122.1.3 Database Operations.......................................................................................................132.1.4 Database Data.................................................................................................................142.1.5 Encryption........................................................................................................................152.1.6 Sound Card......................................................................................................................162.1.7 Speaker Verification.........................................................................................................172.1.8 GUI..................................................................................................................................182.1.9 Verification Processing....................................................................................................192.1.10 Training Processing.........................................................................................................20
3 DEPENDENCY DESCRIPTION.................................................................................................21
3.1 SYSTEM ENTITIES.....................................................................................................................223.1.1 Smart Card Operations....................................................................................................223.1.2 Smart Card Data..............................................................................................................233.1.3 Database Operations.......................................................................................................243.1.4 Database Data.................................................................................................................253.1.5 Encryption........................................................................................................................263.1.6 Sound Card......................................................................................................................273.1.7 Speaker Verification.........................................................................................................283.1.8 GUI..................................................................................................................................293.1.9 Verification Processing....................................................................................................303.1.10 Training Processing.........................................................................................................31
4 INTERFACE DESCRIPTION.....................................................................................................32
4.1 SYSTEM ENTITIES.....................................................................................................................354.1.1 Smart Card Data..............................................................................................................354.1.2 Smart Card Operations....................................................................................................354.1.3 Database Data.................................................................................................................374.1.4 Database Operations.......................................................................................................374.1.5 Encryption........................................................................................................................404.1.6 Sound card.......................................................................................................................414.1.7 Graphical User Interface.................................................................................................424.1.8 Speaker Verification.........................................................................................................454.1.9 Verification Processing....................................................................................................464.1.10 Training Processing.........................................................................................................47
5 DETAILED DESIGN DESCRIPTION........................................................................................48
5.1 SYSTEM ENTITIES.....................................................................................................................485.1.1 Smart Card Operations....................................................................................................485.1.2 Smart Card Data..............................................................................................................505.1.3 Database Operations.......................................................................................................515.1.4 Database Data.................................................................................................................545.1.5 Encryption........................................................................................................................555.1.6 Sound Card......................................................................................................................575.1.7 Speaker Verification.........................................................................................................585.1.8 GUI..................................................................................................................................595.1.9 Verification Processing....................................................................................................615.1.10 Training Processing.........................................................................................................63
Speaker Verification for Smart Cards 3
Software Design Description
FiguresFIGURE 1 - VERIFICATION PROCEDURE......................................................................................................9FIGURE 2 - TRAINING PROCEDURE...........................................................................................................10FIGURE 3 - SMART CARD MODULE DESIGN.............................................................................................11FIGURE 4 - DATABASE OPERATIONS MODULE DESIGN...........................................................................13FIGURE 5 - ENCRYPTION MODULE DESIGN..............................................................................................15FIGURE 6 - SOUND CARD MODULE DESIGN.............................................................................................16FIGURE 7 - SPEAKER VERIFICATION MODULE DESIGN............................................................................17FIGURE 8 - GUI MODULE DESIGN...........................................................................................................18FIGURE 9 - VERIFICATION SUBORDINATES..............................................................................................19FIGURE 10 - TRAINING SUBORDINATES...................................................................................................20FIGURE 12 - DATA FLOW DIAGRAM FOR VERIFICATION MODE................................................................33FIGURE 13 - DATA FLOW DIAGRAM FOR TRAINING MODE.......................................................................34FIGURE 14 - GREETING TO USER..............................................................................................................42FIGURE 15 - MODE SELECTION................................................................................................................42FIGURE 16 - VERIFICATION MODE...........................................................................................................43FIGURE 17 - TRAINING MODE..................................................................................................................43
TablesTABLE 1 - SMART CARD OPERATIONS DATA...........................................................................................48TABLE 2 - SMART CARD DATA................................................................................................................50TABLE 3 - DATABASE OPERATIONS DATA...............................................................................................51TABLE 4: DATABASE FIELDS....................................................................................................................54TABLE 5 - ENCRYPTION DATA.................................................................................................................55TABLE 6 - SOUND CARD DATA................................................................................................................57TABLE 7 - GUI DATA...............................................................................................................................59TABLE 8 - VERIFICATION PROCESSING DATA..........................................................................................61TABLE 9 - TRAINING PROCESSING DATA.................................................................................................63
Speaker Verification for Smart Cards 4
Software Design Description
1 IntroductionThis is the Software Description Specification for the Speaker Verification for Smart Cards project
1.1 Purpose
The Software Design Description (SDD) for this project has been developed in order to give the project a clear direction and understanding of the project during the implementation stages. In this design the project group has tried to identify all of the working components of the system that needs to be developed to satisfy the Software Requirements Specification (SRS), previously developed. Once identified these components are fully described in their structure, function and relationships with other components. The method in which the system operates is also described, the proposed way in which the system is to be tested, and the way in which the SRS is satisfied (traceability). It is the intention of the Project group that in producing this document an independent developer could produce the required model from this design description.
1.2 Scope
This Software Design Description has been written from the top-level, down to algorithms for each individual function that is needed in the system. From this document the system can be developed by project group members, individually taking entities, developing each of these through the algorithms and knowing the interactions needed with other entities by referring to the SDD.
The SDD is divided into four sections:
Decomposition Description Dependency Description Interface Description Detail Description
Decomposition Description:Describes how the system is broken down into distinct entities.
Dependency Description:Shows the relationship between the entities and identifies the dependent entities by defining the shared resources.
Interface Description:Details of external and internal interfaces not provided in the software requirements specification.
Detail Description:Contains the internal details for each entity, including attribute descriptions for identification, processing and data.
The entities identified in the Decomposition Description are carried through each of the other sections to show the structure of the system as a whole.
Speaker Verification for Smart Cards 5
Software Design Description
1.3 Definitions and Acronyms
GUI Graphical User Interfaces
API Application Programming Interface
ASE Aladdin Smart Card Environment
SRS System Requirement Specification
SDD Software Design Description
Smart Card Card with an integrated circuit and memory on the card which communicates to the readers using contacts or can also communicate without contacts.
Aladdin Smart Card Reader Reader box that communicates with Smart Cards.
Speaker Verification Process of identifying a person by speech characteristics
Biometrics: Different human characteristics that all persons have, but all are different in some form, i.e. finger prints, retinas.
PIN Personal Identification Number
Speaker Verification for Smart Cards 6
Software Design Description
1.4 References
EMV ‘96, Integrated Circuit Card Specification for Payment Systems
International Standard ISO/IEC 7816-4
Article: ‘Continuous Speech Verification’, IEEE Signal Processing Magazine, May 1995 Vol 12, No.3
Joseph P. Campbell Jr, ‘Speaker Verification: A Tutorial’
Sadaoki Furui, ‘An Overview of Speaker Verification Technology’
Douglas O’Shaughnessy, ‘Speaker Verification’
W. Rankl and W. Effing; Smart Card Handbook; John Wiley & Sons Ltd, Baffins Lane, Chichester,
West Sussex PO19 1UD, England, Second Edition 1997
ANSI/IEEE Std 1016 – 1987, IEEE Recommended Practice for Software Design Description.
Zoreda, J. L. & Oton, j. M.; Smart Cards; 1994 Artech House Inc., USA
Gurewich, N, & Gurewich, O,; Teach Yourself Visual C++ in Twenty One Days; fourth edition; 1997 Sams Publishing, USA
Sedgewick, R., Algorithms in C++; 1992 Addison and Wesley Publishing Company Inc., USA
Contemporary Cryptology, The Science of Information Integrity; edited by Simmons, G. J.; 1992 IEEE Inc., US
Meyer, C. H. & Matyas, S. M.; Cryptography: A new dimension in computer data security; 1982 John Wiley & Sons Inc., USA
Speaker Verification for Smart Cards 7
Software Design Description
2 Decomposition Description
After analysing the SRS, there were two modes of operation identified in section 2.2 of the SRS, System Modes and States. These modes are to be programmed into the system as two controlling processing modules and are User Verification and User Training. From this, separate flow diagrams of system operations needed to complete these processes were developed, which in turn assisted in the process of identifying the components/entities needed in the system. It is important to note that the separate processes both use the same decomposition of components: their data and functionality.
Verification Procedure:
The project group, see the Verification procedure as the most used function of the system. The process involves a Smart Card being inserted into the reader by a user, the user’s information being taken from the card, the system prompting the user for some speech, the system matching the user’s speech against speech models and displaying the results of the procedure.
Training Procedure:
The second function of the system is to initially train the cards for users and to have the ability to update information, for example speech models or user details. To achieve this the process will be;The user entering a Smart Card, empty or needing a update, obtaining the new user details and speech samples, creating a speech model, and storing the appropriate data on the Smart Card and in the database.
The system is using the following technologies to achieve the required processes: Sound Card for Recording Speech Encryption for Security Database for Storage of User Data Speaker Verification Algorithm for Matching Recorded Speech Against Speech Models Graphical User Interface for Displaying Results and Communication with User
The logical decomposition of the system from the use of these different technologies follows:
1. Smart Card Operations2. Smart Card Data3. Database Operations4. Database Data5. Encryption6. Sound Card7. Speaker Verification8. GUI9. Verification Processing10. Training Processing
The two identified processes, Verification and Training, can be seen in Figure 1 and 2 below in addition to the entities that compose the processes and hence system.
Speaker Verification for Smart Cards 8
Software Design Description
Figure 1 - Verification Procedure
Speaker Verification for Smart Cards 9
Software Design Description
Figure 2 - Training Procedure
Speaker Verification for Smart Cards 10
Software Design Description
2.1 System Entities
2.1.1 Smart Card Operations
Type:The entity “Smart Card Operations” is of the type Interface to External Hardware
Purpose:As part of the project, it is a requirement that Smart Cards be used to contain information about a user (SRS 1.2). That is, a user must have a Smart Card to be able to use the system. The entity “Smart Card Operations” exists because the Smart Card reader and the Smart Cards themselves have to be interfaced with to read and write data. This entity provides the functionality to be able to do that.
Function:This entity provides the functionality to read from, write to and authenticate Smart Cards. The entity “Smart Card Data” describes what data is to be read from and written to the Smart Cards.
Subordinates:The Smart Card component has two sub-components, which together contain all of the functionality needed to communicate with the Smart Card and obtain all of the relevant information. The two sub-components are as follows: Initialisation Card Functionality
Figure 3 - Smart Card Module Design
Speaker Verification for Smart Cards 11
Software Design Description
2.1.2 Smart Card Data
Type:This entity is a data storage element.
Purpose:This entity describes the data storage method on the Smart Cards and hence is a ‘File Structure’ for the Smart Card. This entity is required due to the constraint of limited memory available, as identified in SRS 2.4.
Function:With a specific structure of data on each card, processing of the data held on the card is made easier. This identification of the file structure is also responsible for identifying what information needs to be stored on the Smart Cards. Additional fields may be added if thought to be an addition to the functionality of the system but those identified in this entity are seen as the necessary fields for the system to work.
Subordinates:The data elements that make up this entity are as follows:Verification Certificate, ID, Name, Decryption Key
Speaker Verification for Smart Cards 12
Software Design Description
2.1.3 Database Operations
Type:This entity is an interface to external software.
Purpose:This entity is needed to open and manage an external database by providing routines to return or store data used in the system. The functions contained in this entity are all public, which means that the entity itself can be considered a library object to some central processing program. The need for the database was identified in SRS 3.4 due to the multiple fields needed for each user.
Function:The Database operations entity provides all of the functionality to be able to interface with an Access Database. It will initially connect to the database itself, read data, write data and then disconnect from the database.
Subordinates:The subordinates in this entity are: Connect : Opens the link to Access database Search : Searches table for ID matching card currently inserted Read : Reads entire row and returns the values in each field separately Write : Write entire row Update : Update a single field or multiple fields in a specific row Disconnect : Disconnect from database
Figure 4 - Database Operations Module Design
Speaker Verification for Smart Cards 13
Software Design Description
2.1.4 Database Data
Type:External Access database used for data storage.
Purpose:The use of a database to store large amounts of data simplifies the data storage since the methods needed have already been designed, implemented and tested. This also adds to the robustness of the system. The purpose of having this as an entity is so that all elements in the database can be described formally
Function:The external database is used in this system for storage of application data, which is related to each user. In some fields there are pointers/file names, to where files which are used by the system for a particular user, for example user picture.
Subordinates:The data elements that make up this entity are as follows:ID, Username, Encryption Key, Text for Verification, Speech Model Filename, Picture Filename, Date of Birth, Address, Work/Home Phone numbers, User Access Level.
Speaker Verification for Smart Cards 14
Software Design Description
2.1.5 Encryption
Type:The entity is of the type Data Processing Element
Purpose:Security is a large part of the project as identified in SRS 3.3. Encryption is seen as one of the key elements in the security strategy for the system.
Function:The encryption module generates a public and private key for each new card, the same keys is used for the life of the card and the public key and private key is a distinct pair. This information is stored on the card. The public key is released to the terminal when information related to the cardholder, needs to be stored in the database.
This module also provides the means to encrypt and decrypt information.
Subordinates:Four subordinates are required for this module, they are:
Generate Keys Crypt Information (Encryption and Decryption) Read Data Write Data
Generate Keys: This subroutine performs the generation of the required keys that will be used in encryption process. This method uses the public key cryptosystems.
Crypt Information: This subroutine encrypts or decrypts text depending on the input key to this routine. The encryption/decryption uses power modulo arithmetic to map the text from plain text to cipher text or vice versa.
Read Data: This subroutine reads data from a file, the data is read in as bits.
Write Data: This routine uses the data read in from the Read Data routine, the data is then manipulated by the Crypt Information before it is written to a file.
Figure 5 - Encryption Module Design
Speaker Verification for Smart Cards 15
Software Design Description
2.1.6 Sound Card
Type:This entity is of the type Hardware Interfacing Element.
Purpose:Since the project requires the use of speaker verification as the security biometric (SRS 1.2), a sound card and microphone is required to capture the speech of the user. This entity exists so that the program can interface with the sound card and microphone
Function:The functions of this entity include: Initialising the sound card Retrieving data samples from the sound card
Initialisation of the sound card involves telling the sound card that we require its services. We then specify the following recording parameters: Samples rate ( The number of samples to be taken from the microphone per second ) Sampling accuracy Stereo/Mono recording Number of buffers
Subordinates:This entity contains three elements. They are: Procedure to initialise the sound card Procedure to initialise the interrupts Procedure to retrieve the data from the sound card
Figure 6 - Sound Card Module Design
Speaker Verification for Smart Cards 16
Software Design Description
2.1.7 Speaker Verification
Type:The type of this entity is Data Processing Element.
Purpose:This entity exists because as required in the project (SRS 1.2), the form of security biometric to be used is “Speaker Verification”.
Function:This entity implements the speaker verification procedures/algorithms by comparing a user speech model with a speech sample. It then returns a success/fail result. This entity also has the ability to create user speech models. It does this by analysing a number of speech samples recorded by the user, and extracting features from these speech samples. It then creates a speech model of that user to be used in the verification process.
Subordinates:This entity contains two elements. They are The speaker verification procedure The procedure to create user speech models
Figure 7 - Speaker Verification Module Design
Speaker Verification for Smart Cards 17
Software Design Description
2.1.8 GUI
Type:The entity “GUI” is of the type I/O Device.
Purpose:The Graphical user interface provides an interface where the user can interact with the system. The GUI allows for the user to enter input into the system and also to receive output from the system.
The user input will be their card and a sample of their speech pattern. The GUI will provide a real time view of their sample wave given, and also all the users personal details, if the result from the speech algorithm is successful.
Function:The GUI displays the interaction between the user and the system. It is able to display the following information that is passed to it:
That a card is present in the system The speech sample The outcome of the verification process. The users personal details
Subordinates:This interface requires the following subordinates to perform the above tasks:
Card Present Display Results Display Waveform Display Personal Information
Card Present: This subroutine waits for a windows event from the card reader and displays the result as either a card is present or absent from the system.
Display Results: Waits for incoming data from the speech verification algorithm and displays the outcome from that process.
Display Waveform: Waits for incoming data from the sound card and displays the person’s speech pattern in real time.
Display Personal: Display the personal details of the cardholder that it obtains from the database.
Figure 8 - GUI Module Design
Speaker Verification for Smart Cards 18
Software Design Description
2.1.9 Verification Processing
Type:The entity “Verification Processing” is a Processing Element.
Purpose:The entity “Verification Processing” is one of the two possible modes of operation in the project (SRS 2.2). This entity exists to control the flow of the verification procedure that is the main requirement of the project.
Function:The function of this entity is to implement the verification procedure outlined in Figure 1 using all of the entities. This entity will also handle events produced by the Sound Card, the Smart Card and the GUI entities.
Subordinates:The Verification Processing entity does more than just the verification procedure. This entity handles all of the “events” that occur in the verification part of the program. These events can be broken down into three parts. These are: Events caused by the user pressing a key or clicking the mouse Events caused by the sound card Events caused by the smart card readerThe following diagram shows how these events are handled by the entity.
Figure 9 - Verification Subordinates
Speaker Verification for Smart Cards 19
Software Design Description
2.1.10 Training Processing
Type:The entity “Training Processing” is a Processing Element
Purpose:The entity “Training Processing” is the other of the two possible modes of operation in the project (SRS 2.2). This entity exists to control the flow of the speech training procedure that is required before the verification procedure can take place.
Function:The function of this entity is to implement the training procedure outlined in Figure 2 using all of the entities. This entity will also handle events produced by the Sound Card, the Smart Card and the GUI entities.
Subordinates:The Training Processing entity does a similar job to that of the Verification Processing entity.
Figure 10 - Training Subordinates
Speaker Verification for Smart Cards 20
Software Design Description
3 Dependency Description
After breaking down the system in entities and identifying each of these entities, it is necessary to identify the entities that rely on other entities to do their work. That is, identify which entities each entity is dependent on. Describing the dependencies of each entity helps identify what functionality each of the entities needs to provide to maintain a coherent system. The two diagrams in the previous section (Figure 1and Figure 2) provide an insight into the dependencies of the entities “Verification Processing” and “Training Processing”. These diagrams provide a starting point to describing the dependencies of each entity.
Speaker Verification for Smart Cards 21
Software Design Description
3.1 System Entities
3.1.1 Smart Card Operations
Type:The entity “Smart Card Operations” is of the type Interface to External Hardware
Purpose:As part of the project, it is a requirement that Smart Cards be used to contain information about a user (SRS 1.2). That is, a user must have a Smart Card to be able to use the system. The entity “Smart Card Operations” exists because the Smart Card reader and the Smart Cards themselves have to be interfaced with to read and write data. This entity provides the functionality to be able to do that.
Dependencies:The entity “Smart Card Operations” is used by other entities as a ‘tool’. The initialisation of the Smart Card reader is done at the start of the program. The read and authentication operations are called whenever a Smart Card is inserted into the reader. The write operation is used only in “Training Mode” when a new user is created and the data is transferred onto the card.
Timing and Sequencing:The Smart Card Module has a set sequencing of events that cannot be varied from greatly. Firstly the initialisation of the hardware components involved must occur so before anything else will work. Inside the Initialisation sub-component the Smart Card Reader must be supplied power, then the interrupts turned on and finally the reader must check to see if there is already a card in the reader. If there is a card in the reader then the module can immediately proceed with the Card Functionality sub-component, if there is no card then the module must wait for interrupts to start the Card Functionality. Once inside the Card Functionality unit the PC terminal, through the Smart Card Reader, will initialise communication with the Smart Card by firstly authenticating the card by challenging the card for a correct certificate. Dependent upon the success of the authentication, the sub-component can start sending messages and receiving data or receiving success/failure messages. Once the terminal is finished communicating with the card then it closes the Card Functionality sub-component and once again the Smart Card module waits for interrupts to initialise the Card Functionality sub-component. While the Card Functionality sub-component is operating, the interrupts (ie. Smart Card Removed) can occur at any time and hence are polled for continuously.
Resources:The entity “Smart Card Operation” relies on the Aladdin Smart Card Reader and the application-programming interface provided with the Aladdin system to interface with the reader. It also relies on the presence of a Smart Card to be able to read and write to one.
Speaker Verification for Smart Cards 22
Figure 11: Smart Card Module Sequencing
Software Design Description
3.1.2 Smart Card Data
Type:This entity is a data storage element.
Purpose:This entity describes the data storage method on the Smart Cards and hence is a ‘File Structure’ for the Smart Card. This entity is required due to the constraint of limited memory available, as identified in SRS 2.4.
Dependencies:The Smart Card is dependent upon the Smart Card Operations entity and to communicate with this entity it uses the ASE API. This entity is also restricted in the amount of storage it can have due to the memory storage capabilities of the Smart Cards, approx. 8kb. Also identified in SRS 2.6.2.1 is the assumption that the Smart Cards will not be corrupted.
Resources:This Smart Card entity uses ASE Smart Cards and the ASE API.
Speaker Verification for Smart Cards 23
Software Design Description
3.1.3 Database Operations
Type:This entity is an interface to external software.
Purpose:This entity is needed to open and manage an external database by providing routines to return or store data used in the system. The functions contained in this entity are all public, which means that the entity itself can be considered a library object to some central processing program. The need for the database was identified in SRS 3.4 due to the multiple fields needed for each user.
Dependencies:The Database Operations entity only interacts with two external entities, that of the central processing entity and the Database entity. The dependencies arising from interaction with these two entities are listed below.
Database entity Microsoft Access Table being used. Table with correct fields
Processing entity: Send appropriate data when writing to database Prompting for initialisation of database.
Resources:The external database used by the system is to be Microsoft Access, which is now readily available and installed on most computers, due to the fact that it comes together with Microsoft Office which is the preferred choice of most users in regards to word processing.This entity has the following external resources:
SQL Access Database
Speaker Verification for Smart Cards 24
Software Design Description
3.1.4 Database Data
Type:External Access database used for data storage.
Purpose:The use of a database to store large amounts of data simplifies the data storage since the methods needed have already been designed, implemented and tested. This also adds to the robustness of the system. The purpose of having this as an entity is so that all elements in the database can be described formally.
Dependencies:The entity is reliant on the ID variable being unique, as this will be used as the primary key to the database.
Resources:The database that is used in this Database entity is Microsoft Access.
Speaker Verification for Smart Cards 25
Software Design Description
3.1.5 Encryption
Type:The entity is of the type Data Processing Element
Purpose:Security is a large part of the project as identified in SRS 3.3. Encryption is seen as one of the key elements in the security strategy for the system.
Dependencies:The encryption module relies on the input from the database and the Smart Card. It then supplies the decrypted information about the user to the GUI and the decrypted speech model to the speech verification module.
Resources:This module requires the input from the database for the speech model. Using the decryption key that is stored on the card the model is decrypted so that it can be used by the speech verification module.
Speaker Verification for Smart Cards 26
Software Design Description
3.1.6 Sound Card
Type:This entity is of the type Hardware Interfacing Element.
Purpose:Since the project requires the use of speaker verification as the security biometric, a sound card and microphone is required to capture the speech of the user. This entity exists so that the program can interface with the sound card and microphone
Dependencies:The entity “Sound Card” is a relatively independent one. It takes no inputs.The entity “Speaker Verification” is dependent on it for the speech samples from the user.
Resources:Obviously, this entity uses the following external resources: Sound Card Microphone
Speaker Verification for Smart Cards 27
Software Design Description
3.1.7 Speaker Verification
Type:The type of this entity is Data Processing Element.
Purpose:This entity exists because as required in the project (SRS 1.2), the form of security biometric to be used is “Speaker Verification”.
Dependencies:The Speaker Verification entity has two sources of input. These are speech samples, received from the entity “Sound Card” and the decrypted speech model, received from the entity “Encryption”.
On creation of the user speech model, the model is sent to the entity “Encryption” to be encrypted. It is then sent to the entity “Database”.
The Speaker Verification module makes some allowances in its processing due to the assumptions and dependencies stated in the SRS. These being:
SRS 2.6.1.2 The speech sample from the user will have the text spoken correctly, not repeated or stopped half way through and hence need to be repeated.
SRS 2.6.3.2 The microphone and sound card used is able to record the user speech to a quality good enough for the voice verification software.
Resources:At this stage in the project, the speaker verification methods are contained within a library file that is included when compiling the program. This is the only external resource used by the Speaker Verification entity.
Speaker Verification for Smart Cards 28
Software Design Description
3.1.8 GUI
Type:The entity “GUI” is of the type I/O Device.
Purpose:The Graphical user interface provides an interface where the user can interact with the system. The GUI allows for the user to enter input into the system and also to receive output from the system.
The user input will be their card and a sample of their speech pattern. The GUI will provide a real time view of their sample wave given, and also all the users personal details, if the result from the speech algorithm is successful.
Dependencies:The GUI module requires information to be sent to it from the sound card, the speech verification and the database modules.
The only output the GUI provides to the internal system is to inform the Smart Card module that a card has been entered into the system or that one has been removed. The GUI is not directly concerned with the other modules of the system.
The GUI component is also reliant upon the assumption that users of the system have enough skill that they are able to operate the GUI. This assumption was stated in the SRS 2.6.3.1.
Resources:Visual C++ graphical tools were used to create the graphical user interface. This interface uses the Window’s API to determine if there is a card in the reader.
Speaker Verification for Smart Cards 29
Software Design Description
3.1.9 Verification Processing
Type:The entity “Verification Processing” is a Processing Element.
Purpose:The entity “Verification Processing” is one of the two possible modes of operation in the project (SRS 2.2). This entity exists to control the flow of the verification procedure that is the main requirement of the project.
Dependencies:As the Verification Processing entity is a controlling entity, it is dependent upon the other entities to provide it with the resources it needs. The entity is not in direct control over any pieces of hardware, but it uses the other entities as library files to control the hardware attached to, and used but the system. This entity also uses other entities for storage of application data and processing of information.
The entities used by the Verification Processing entity include:Smart Card Operations, Smart Card Data, Database Operations, Database Data, Encryption, Sound card, Speaker Verification and GUI.
Resources:The Verification Processing entity, when being used is in control of the system, not directly in control of the hardware or external software being used by the system, but using the entities that do control these things. As such this entity has no need of resources other than processing and memory storage capabilities and the ability to control the other entities.
Speaker Verification for Smart Cards 30
Software Design Description
3.1.10 Training Processing
Type:The entity “Training Processing” is a Processing Element
Purpose:The entity “Training Processing” is the other of the two possible modes of operation in the project (SRS 2.2). This entity exists to control the flow of the speech training procedure that is required before the verification procedure can take place.
Dependencies:As the Verification Processing entity is a controlling entity, it is dependent upon the other entities to provide it with the resources it needs. The entity is not in direct control over any pieces of hardware, but it uses the other entities as library files to control the hardware attached to, and used but the system. This entity also uses other entities for storage of application data and processing of information.
The entities used by the Verification Processing entity include:Smart Card Operations, Smart Card Data, Database Operations, Database Data, Encryption, Sound card, Speaker Verification and GUI.
Resources:The Training Processing entity, when being used is in control of the system, not directly in control of the hardware or external software being used by the system, but using the entities that do control these things. As such this entity has no need of resources other than processing and memory storage capabilities and the ability to control the other entities.
Speaker Verification for Smart Cards 31
Software Design Description
4 Interface DescriptionThe decomposition description shows know how the system should behave, from here we can identify the entities that are needed, the functions they perform and how they interact within the system.
The system has been designed with six entities they are:
Smart Card Database Encryption Sound card Graphical user interface Speaker verification
For the two different modes of operations the data flow between the entities varies.
Verification Mode
For the verification mode the system requires two external data inputs, these are the users card and a sample of their voice. Once the system has this information it will begin to process this information along with the data it has access to it from the database. The speech verification entity uses the decrypted speech model and the speech sample to determine if they are the same people. If the result from this test is successful in the view of the cardholder then restricted information is allowed to be display by the GUI, otherwise this information is withheld.
Training Mode
The training mode’s flow of data is similar to the verification mode, however it handles more speech samples. Once four speech samples have been entered into the system the speech verification module creates the speech module from the average of the four inputs samples. Using the encryption entity it then encrypts this model. A reference to this model is stored in the database corresponding to the card id. Also stored in the database is information about the cardholder.
Speaker Verification for Smart Cards 32
Software Design Description
Figure 12 - Data flow diagram for verification mode
Speaker Verification for Smart Cards 33
Software Design Description
Figure 13 - Data flow diagram for training mode
Speaker Verification for Smart Cards 34
Software Design Description
4.1 System Entities
4.1.1 Smart Card Data
FunctionWith a specific structure of data on each card, processing of the data held on the card is made easier. This identification of the file structure is also responsible for identifying what information needs to be stored on the Smart Cards. Additional fields may be added if thought to be an addition to the functionality of the system but those identified in this entity are seen as the necessary fields for the system to work.
InterfacesThis entity is one that is used to describe the data storage on the Smart Cards, and hence has no interfaces.
4.1.2 Smart Card Operations
FunctionThis entity provides the functionality to read from, write to and authenticate Smart Cards. The entity “Smart Card Data” describes what data is to be read from and written to the Smart Cards.
InterfacesFrom the Smart Card module, other components will be able to write to, and read from the card, using the read and write functions contained in the Card Functionality sub-component. The data accessible from the read function will be all of the data entities stored on the card, as separate variables. When writing to the card, the data passed to the write function will have to be of correct formatting, for example all entities present, of the correct data type and correct length. If this is not the case then the write method will return an error message to the calling method.
Initialisation
Procedure TurnOnReader
int TurnOnReader (void);
Input/Output Name Type DescriptionO Return Value int The method returns a success/fail result:
‘1’ for success‘0’ for failure
Procedure TurnOnInterrupts
int TurnOnInterrupts(void);
Input/Output Name Type DescriptionO Return Value Int The method returns a success/fail result:
‘1’ for success‘0’ for failure
Speaker Verification for Smart Cards 35
Software Design Description
Procedure CheckInitialCard
int CheckInitialCard(void);
Input/Output Name Type DescriptionO Return Value Int Returns ‘1’ if there is a
card in the reader, ‘0’ if not.
Card Functionality
Procedure Authentication
int Authentication(void);
Input/Output Name Type DescriptionO Return Value Int Returns ‘1’ if authentication is successful, returns ‘0’
if not.
Procedure ReadCardData
int ReadCardData(int *CardID, CString *UserName, DWORD *DecryptKey);
Input/Output Name Type DescriptionO CardID int The Card Identification numberO UserName String The name of owner of the cardO DecryptKey DWORD The decryption key for the databaseO Return Value int Returns a success/fail result:
‘1’ if data read successfully‘0’ if not.
Procedure WriteCardData
Int WriteCardData(int CardID, CString UserName, DWORD DecryptKey);
Input/Output Name Type DescriptionI CardID int The Card Identification numberI UserName String The name of owner of the cardI DecryptKey DWORD The decryption key for the databaseO Return Value int Returns a success/fail result:
‘1’ if data read successfully‘0’ if not.
Speaker Verification for Smart Cards 36
Software Design Description
4.1.3 Database Data
FunctionThe external database is used in this system for storage of application data, which is related to each user. In some fields there are pointers/file names, to where files which are used by the system for a particular user, for example user picture.
InterfacesThe Access database communicates with the system through the Windows API. The Database entity is directly controlled by the Database Operations entity, hence it needs no functionality other than data storage.
4.1.4 Database Operations
FunctionFollowing is a list of what the entity is capable of doing and needs to do so that it can operate the database.
1. Opens the link to Access database2. Searches table for ID matching card currently inserted3. Reads entire row and returns the values in each field separately4. Write entire row.5. Update a single field or multiple fields in a specific row6. Disconnect from database
All of these capabilities are built into individual functions, which are publicly accessible.
InterfacesAs already described this entity is connected to two other entities only. The information passed between them consists of:
Procedure DatabaseConnect
int DatabaseConnect(DWORD DatabaseName, DWORD *DatabaseHandle);
Input / Output Name Type DescriptionI Database name DWORD Table file nameO Status Integer Success of procedure, 1
for success and 0 for failure
O Database handle DWORD Variable for control of the database during processing
Speaker Verification for Smart Cards 37
Software Design Description
Procedure SearchID
int SearchID(int UserID, int *Recordno, CString *Message);
Input / Output Name Type DescriptionI User ID from Smart
CardInteger Random Integer used as
primary key to the database
O Status Integer Success of procedure, 1 for success and 0 for
failureO Record no.
OrMessage
Integer
String
Pointer to the record in the database
corresponding to the user
Error message for no record with that User ID
Procedure ReadRow
int ReadRow(int Recordno, UserInfo *user)
Input / Output Name Type DescriptionI Record no. Integer Pointer to the user’s
record in the tableO Status Integer Success of procedure, 1
for success and 0 for failure
O User object Name Encryption key User’s text User’s Speech
pattern Picture File
name DOB Street Suburb Work Phone
Number Home Phone
Number User Access
Level
Object with public variables
The User object is a data storage class into which all of the user’s details are read from the database. The use of an object makes passing of information around the system cleaner and more efficient.
Speaker Verification for Smart Cards 38
Software Design Description
Procedure WriteRow
int WriteRow(Userinfo user)
Input / Output Name Type DescriptionI User Object Data Storage Object Object containing public
variables with a users personal information stored in each.
O Status Integer Success of procedure, 1 for success and 0 for failure
Procedure UpdateRow
int UpdateRow(Userinfo user,int Recordno);
Input / Output Name Type DescriptionI User Object Data Storage Object Object containing public
variables with a users personal information stored in each.
I Record no. Integer Pointer to the record number in the table for the user.
O Status Integer Success of procedure, 1 for success and 0 for failure
Procedure Disconnect
int Disconnect(void);
Input / Output Name Type DescriptionO Status Integer Success of procedure, 1
for success and 0 for failure
Speaker Verification for Smart Cards 39
Software Design Description
4.1.5 Encryption
FunctionThe encryption module generates a public and private key for each new card, the same keys is used for the life of the card and the public key and private key is a distinct pair. This information is stored on the card. The public key is released to the terminal when information related to the cardholder needs to be stored in the database.
This module also provides the means to encrypt and decrypt information
InterfacesBefore the encryption module can encrypt or decrypt information it needs to provide a card with a public key and private key pair. Once this process has been performed the keys are not intended to be changed during the life of the card, unless the private key has been compromised.
During everyday use of the card the module needs to be supplied with data to be encrypted/decrypted and the appropriate key from the card. The data that the module deals with is information stored in the database. The only encrypted information is the file containing the speech model.
Procedure Generate Keys
int GenerateKeys(DWORD *PublicKey, DWORD *PrivateKey);
Input/Output Name Type DescriptionO PublicKey DWORD Ordered pair containing the modulus value and
the public key exponential number.O PrivateKey DWORD Ordered pair containing the modulus value and
the private key exponential number.
Procedure Crypt Information
int CryptInfo(FILE *PlainFile, DWORD Key, FILE *CipherFile);
Input/Output Name Type DescriptionI Plain File FILE The file that the encryption/decryption algorithm
alters.I Key DWORD The key required by the algorithm.O Cipher File FILE The file containing the result of the algorithm.
Speaker Verification for Smart Cards 40
Software Design Description
4.1.6 Sound card
FunctionThe functions of this entity include: Initialising the sound card Retrieving data samples from the sound card
Initialisation of the sound card involves telling the sound card that we require its services. We then specify the following recording parameters: Samples rate ( The number of samples to be taken from the microphone per second ) Sampling accuracy Stereo/Mono recording Number of buffers
InterfacesThe entity “Sound Card” and its methods will be encapsulated within a class in the program.
This entity interacts with other entities through the three methods: InitSound InitSoundInterrupts GetSpeechSample
The method InitSound has no parameters, it simply returns a success/fail result. This will be ‘1’ for success and ‘0’ for failure.
The InitSoundInterrupts method also has no parameters and it also returns a success/fail result. It returns ‘1’ for success and ‘0’ for failure.
The method GetSpeechSample has one parameter. This will be an array of fixed length and on completion of the method it will contain the last speech sample recorded by the sound card. The method will also return a success/fail result. This will be ‘1’ for success and ‘0’ for failure.
Procedure InitSound
int InitSound(void);
Input/Output Name Type DescriptionO Procedure
Successint Returns 1 for success and 0 for failure
Procedure InitSoundInterrupts
int InitSoundInterrupts(void);
Input/Output Name Type DescriptionO Procedure
Successint Returns 1 for success and 0 for failure
Procedure GetSpeechSample
int GetSpeechSample(int Speech[]);
Input/Output Name Type DescriptionO Speech Array Array of int Array containing last speech sample recorded by
sound cardO Procedure
Successint Returns 1 for success and 0 for failure
Speaker Verification for Smart Cards 41
Software Design Description
4.1.7 Graphical User Interface
FunctionThe GUI displays the interaction between the user and the system. It is able to display the following information that is passed to it:
That a card is present in the system The speech sample The outcome of the verification process. The users personal details
The following are screenshots of the GUI in its different modes of operation.
Figure 14 - Greeting to User
Figure 15 - Mode Selection
The Mode Selection dialog window as seen in Figure 15 lets the user choose which type of operation they want to perform once the card has been inserted. There will be some circumstances that the system will take the user automatically to training mode, for example a corrupted card or empty card.
These next screens are preliminary designs for the verification and training screens for the system. These may change depending upon the fields that are deemed to be necessary to the system and the possible features added.
Speaker Verification for Smart Cards 42
Software Design Description
Figure 16 - Verification Mode
Figure 17 - Training Mode
InterfacesThe GUI initiates the system for a new client. The GUI informs other modules that a card has arrived, it then waits in the Smart Card module for confirmation that the card is valid. Once this has been achieved the GUI prompts the user to speak into the microphone. The speech verification module is passed to the speech sample and used for verification of the cardholder. The result of the verification
Speaker Verification for Smart Cards 43
Software Design Description
process determines if more information is needed to obtain from the database, if this is the case then it is displayed.
Procedure CardPresent
int CardPresent(void);
Inputs/Outputs Name Type DescriptionO Return Value int The method returns a success/fail result:
‘1’ for success‘0’ for failure
Procedure Display Results
int DisplayResults(void);
Inputs/OutputsName Type Description
O Return Value int The method returns a success/fail result:‘1’ for success‘0’ for failure
Procedure Display Waveform
int DisplayWaveform(int *SpeechSample);
Inputs/Outputs Name Type DescriptionI Speech sample int * The coordinates of the speech sampleO Return Value int The method returns a success/fail result:
‘1’ for success‘0’ for failure
Procedure Display Personal
int DisplayPersonal(UserInfo info);
Inputs/Outputs Name Type DescriptionI User Object Data Storage Object Object containing public
variables with a users personal information
stored in each.O Return Value int The method returns a
success/fail result:‘1’ for success‘0’ for failure
Speaker Verification for Smart Cards 44
Software Design Description
4.1.8 Speaker Verification
FunctionThis entity implements the speaker verification procedures/algorithms by comparing a user speech model with a speech sample. It then returns a success/fail result. This entity also has the ability to create user speech models. It does this by analysing a number of speech samples recorded by the user, and extracting features from these speech samples. It then creates a speech model of that user to be used in the verification process.
InterfacesThe entity “Speaker Verification” and its methods will be encapsulated within a class in the program.
This entity interacts with other entities through the two methods: TrainSpkrModel
Procedure TrainSpkrModel
int TrainSpkrModel(char *spkrID, char *allFileNames[], int numFiles );
Input/Output Variable Name Type DescriptionI spkrID char * The name of the userI allFileNames char * [] Array of filenames
containing the speech samples
I numFiles int The number of filenames listed in the above array
O Return Value int The method returns a success/fail result:‘1’ for success‘0’ for failure
Upon success, this method creates a user speech model. The speech model is stored in a file called “UserName.HMM”
SpkrVerif
The function prototype for this method is as follows:
Procedure SpkrVerif
int SpkrVerif( char *fileName, char *spkrID );
Input/Output Variable Name Type DescriptionI fileName char * The name of the file
containing the speech sample
I spkrID char * The name of the userO Return Value int The method returns a
success/fail result:‘1’ for success‘0’ for failure
Speaker Verification for Smart Cards 45
Software Design Description
4.1.9 Verification Processing
Function:The function of this entity is to implement the verification procedure outlined in Figure 1 using all of the entities. This entity will also handle events produced by the Sound Card, the Smart Card and the GUI entities.
Interfaces:This entity requires
Procedure Verify user
int VerifyUser(Cstring *ErrorMessage);
Inputs/Outputs Name Type DescriptionO Return Value int The method returns a success/fail
result:‘1’ for success‘0’ for failure
O Error Message String Informs the user what type of erro has occurred.
Procedure Initialisation
int Initialise(void);
Inputs/Outputs Name Type Description(none)
Procedure SmartCardInserted
void SmartCardInserted(void);
Inputs/Outputs Name Type Description(none)
Procedure SpeechSample
void SpeechSample(void);
Inputs/Outputs Name Type Description(none)
Speaker Verification for Smart Cards 46
Software Design Description
4.1.10 Training Processing
Function:The function of this entity is to implement the training procedure outlined in Figure 2 using all of the entities. This entity will also handle events produced by the Sound Card, the Smart Card and the GUI entities.
Interfaces:Procedure Train userint TrainUser(CString *ErrorMessage);
Inputs/Outputs Name Type descriptionO Return Value int The method returns a success/fail
result:‘1’ for success‘0’ for failure
O Error Message String Informs the user what type of erro has occurred.
Procedure Initialisationint Initialise(void);
Inputs/Outputs Name Type Description(none)
Procedure SmartCardInsertedvoid SmartCardInserted(void);
Inputs/Outputs Name Type Description(none)
Procedure SpeechSamplevoid SpeechSample(void);
Inputs/Outputs Name Type Description(none)
Procedure Authenticationvoid Authentication(void);
Inputs/Outputs Name Type Description(none)
Procedure ProcessUserInputvoid ProcessUserInput(void);
Inputs/Outputs Name Type Description(none)
Procedure CreateSpeechModelvoid CreateSpeechModel(void);
Inputs/Outputs Name Type Description(none)
Speaker Verification for Smart Cards 47
Software Design Description
5 Detailed Design Description
The Detailed Design Description contains the planned implementation of each identified entity, its data and functions. For each entity there are tables showing the data used by each entity, both that which is passed into and out of the entity and the internal data needed for processing in the entity. Following the data description is a listing of pseudo code for each function, which is to be contained in each entity.
5.1 System Entities
5.1.1 Smart Card Operations
DataThe following data will be used by this entity having taken it from the Smart Card.
Name Description SizePassword For use with Memory Protected
Smart Cards, needed to read and write from card.
8 bytes
State Current state of the Smart Card inserted.
1 byte
Verification Certificate Standard certificate showing that this is a project Smart Card with valid data contained on it.
128 bits
ID Pointer to database record. 4 bytesName String for user name. 100 bytesDecryption Key Decryption Key to the encrypted
speech file stored on the terminal.128 bits
Table 1 - Smart Card Operations Data
ProcessingInitialization
Procedure TurnOnReader
Call ASEReaderOpenByName
Input/Output Name Type DescriptionO Return Value Int The method returns a success/fail result:
‘1’ for success‘0’ for failure
Procedure TurnOnInterrupts
Call ASEReaderSetMessage
Input/Output Name Type DescriptionO Return Value Int The method returns a success/fail result:
‘1’ for success‘0’ for failure
Speaker Verification for Smart Cards 48
Software Design Description
Procedure CheckInitialCard
Call ASEGetCardStatus If there is a card in the reader
Call CardPowerOnReturn ‘1’
Else Return ‘0’
Input/Output Name Type DescriptionO Return Value Int Returns ‘1’ if there is a
card in the reader, ‘0’ if not.
Card Functionality
Procedure Authentication
Call ASE depending on type of cardCall AuthenticateIf Authenticate OK
Return successElse
Return fail
Input/Output Name Type DescriptionO Return Value Int Returns ‘1’ if authentication is successful, returns ‘0’
if not.
Procedure ReadCardData
Call ReadDataExtract Card Id, User Name, Decryption KeyIf extraction is successful
Return (Card Id, User Name, Decryption Key) & (success)Else
Return failure
Input/Output Name Type DescriptionO CardID int The Card Identification numberO UserName String The name of owner of the cardO DecryptKey DWORD The decryption key for the databaseO Return Value int Returns a success/fail result:
‘1’ if data read successfully‘0’ if not.
Procedure WriteCardData
Pack Card Id, User Name, Decryption KeyCall WriteDataIf data written successfully
Return successElse
Return failure
Input/Output Name Type DescriptionI CardID int The Card Identification numberI UserName String The name of owner of the cardI DecryptKey DWORD The decryption key for the databaseO Return Value int Returns a success/fail result:
Speaker Verification for Smart Cards 49
Software Design Description
‘1’ if data read successfully, ‘0’ if not.
5.1.2 Smart Card Data
Data
As the system is using Memory Protected Smart Cards, there is a need to map out where each piece of information is to be stored and the maximum amount of room it is allowed. This is done so that when a terminal reads a block of information from the card, it knows what information it is getting.
The following is a listing of the data, the order in which it is stored and the size of each field.
Name Description SizeVerification Certificate Standard certificate showing that
this is a project Smart Card with valid data contained on it.
128 bits
ID Pointer to database record. 4 bytesName String for user name. 100 bytesDecryption Key Decryption Key to the encrypted
speech file stored on the terminal.128 bits
Table 2 - Smart Card Data
The memory map shown below starts at 0F due to the fact that there is a protected bit at 00 which caters for the passwords, and hence no other information may be written to this location. Each of the other fields after the Verification Certificate follows sequentially and leaves no room after the previous one.
Speaker Verification for Smart Cards 50
42F3AF8F
0F
Verification Certificate128 bits
ID4 bytes
Name100 bytes
Decryption Key128 bits
Figure 18: Memory Map for Memory Protected Smart Cards
Software Design Description
5.1.3 Database Operations
Data
The data needed for the processing of the Database Operations Entity is listed below.
Name Description SizeUser Object Storage object containing a public
variable for each field of the database. Include: ID, name, address, picture, decryption, dob, phone numbers and access level
Database Handle Pointer to database 4 bytesCursor Position Pointer to current record in
database1 byte
Table 3 - Database Operations Data
The User Object is seen as an efficient method of passing information around the system, rather than passing many individual variables. There can be only one instance of the User Object in the system at one time, being created only in the Database Operations entity and being destroyed in the clean up procedures of the system.
ProcessingThe following is a listing of the functions contained in the entity with an algorithm as to how the function operates, and its inputs and outputs.
Procedure DatabaseConnect
Connect to DatabaseReturn database handle and status = 1
Input / Output Name Type DescriptionI Database name DWORD Table file nameO Status Integer Success of procedure, 1
for success and 0 for failure
O Database handle DWORD Variable for control of the database during processing
Procedure SearchID
Set Cursor to first record
If PointerID from Smart Card = ID in DatabaseReturn Record no.
elseif record = last record
return ‘Not Found’Update Cursor to next record
return Record no. & status = 1
Speaker Verification for Smart Cards 51
Software Design Description
Input / Output Name Type DescriptionI User ID from Smart
CardInteger Random Integer used as
primary key to the database
O Status Integer Success of procedure, 1 for success and 0 for failure
O Record no.
OrMessage
Integer
String
Pointer to the record in the database corresponding to the user
Error message for no record with that User ID
Procedure ReadRow
Read Row from table;Assign variables to Object variables;Return status = 1;
Input / Output Name Type DescriptionI Record no. Integer Pointer to the user’s
record in the tableO Status Integer Success of procedure, 1
for success and 0 for failure
O User object Name Encryption key User’s text User’s Speech
pattern Picture File
name DOB Street Suburb Work Phone
Number Home Phone
Number User Access
Level
Object with public variables
The User object is a data storage class into which all of the user’s details are read from the database. The use of an object makes passing of information around the system cleaner and more efficient.
Speaker Verification for Smart Cards 52
Software Design Description
Procedure WriteRow
Create new Record at end of tableWrite Row into tableReturn status = 1
Input / Output Name Type DescriptionI User Object Data Storage Object Object containing public
variables with a users personal information stored in each.
O Status Integer Success of procedure, 1 for success and 0 for failure
Procedure UpdateRow
Set Cursor to correct RecordWhile number of new fields is != 0
Write data to appropriate fieldDecrement counterReturn status = 1
Input / Output Name Type DescriptionI User Object Data Storage Object Object containing public
variables with a users personal information stored in each.
I Record no. Integer Pointer to the record number in the table for the user.
O Status Integer Success of procedure, 1 for success and 0 for failure
Procedure Disconnect
Disconnect from DatabaseReturn status.
Input / Output Name Type DescriptionI (none)O Status Integer Success of procedure, 1
for success and 0 for failure
Speaker Verification for Smart Cards 53
Software Design Description
5.1.4 Database Data
Data
The following is a listing of the fields stored in the database. The first five of these variables are needed by the system to operate, the rest are seen as variables that may be used in an fully developed system.
Name Description TypeID Primary Key to the database,
supplied by the Smart CardIntegers
User Name Name of the user StringEncryption Key Key used to encrypt speech file Pairs of IntegersText for Verification Text spoken by user on each
attempt of verificationString
Speech Model File Name File name for encrypted Speech file
String
Picture File Name File name for user Picture file StringDate of Birth Date of birth of user Integers (ddmmyy)Street Street in which user lives StringSuburb Suburb in which user lives StringWork Phone Number Phone number of user’s work
placeIntegers
Home Phone Number Phone number to user’s home IntegersUser Access Level Level of access for user to
system.String
Table 4: Database Fields
Speaker Verification for Smart Cards 54
Software Design Description
5.1.5 Encryption
Data
The data needed for encryption entity is listed in the table below. In the case that the system is being used for training, the input file will be of normal format and after processing by this entity it will be encrypted. If the system is in verification mode, the entity will be used to decrypt the encrypted speech model stored for a particular user.
Name Description SizeInput file Encrypted Speech model file
OrDecrypted Speech model file
Output file Decrypted Speech model fileOrEncrypted Speech model file
Public key Prime number used to encrypt a file
128 bits
Private key Prime number used to encrypt a file
128 bits
Table 5 - Encryption Data
Processing
The GenerateKeys procedure obtains the prime number from a lookup table that contains suitable large prime numbers. The table provides the routine with p, q and d.
Where p = prime numberq = prime numberd = private exponential number
Procedure Generate Keys
Initialise two integers p and qGet p and q from the look up tableLet n = p.qLet m = (p-1).(g-1)Do
Get d from the look up tableUntil d is relatively prime to m, and d<mCalculate e such that e.d 1 (mod n)
Public key = (n, e)Private key = (n, d)
Input/Output Name Type DescriptionO PublicKey DWORD Ordered pair containing the modulus value and
the public key exponential number.O PrivateKey DWORD Ordered pair containing the modulus value and
the private key exponential number.
Speaker Verification for Smart Cards 55
Software Design Description
Procedure Crypt Information
From LSB to MSBIf bit is the first bit
C = m modulo nElse
If bit == 0m = square(m)
elsem = square(m)c *= (m modulo n)
endc = m modulo n
where m = part of the plain text messagec = cipher text
NB m and c correspond to the encryption process and can be swapped in the algorithm for the decryption process without further alterations to the algorithm.
Input/Output Name Type DescriptionI Plain File FILE The file that the encryption/decryption algorithm
alters.I Key DWORD The key required by the algorithm.O Cipher File FILE The file containing the result of the algorithm.
Speaker Verification for Smart Cards 56
Software Design Description
5.1.6 Sound Card
Data
The only data used in this entity is the speech sample recorded by the sound card itself. This will be an array of chars of a fixed length. From this array, a speech file can be created for use with the speaker verification entity. This can be done by writing the array to a file (The file will contain more than one speech sample to make up the speech sentence spoken by the user.). The filename will be ‘Sample#.RAW’.
Name Description SizeSpeech Sample Array of chars Fixed LengthSample#.RAW Speech Sample file
Table 6 - Sound Card Data
ProcessingProcedure InitSound
Set WAVformat = WAVE_FORMAT_PCMSet NumChannels = 1Set SamplesPerSec = 8000Set BitsPerSample = 16Open WAV devicePrepare buffers to hold sample dataIf WAV device open OK
Return ‘1’Else
Return ‘0’
Input/Output Name Type DescriptionO Procedure
Successint Returns 1 for success and 0 for failure
Procedure InitSoundInterruptsSetup CallbacksStart WAV deviceIf WAV device started OK
Return ‘1’Else
Return ‘0’
Input/Output Name Type DescriptionO Procedure
Successint Returns 1 for success and 0 for failure
Procedure GetSpeechSampleCopy Sample stored in buffer to SpeechArrayReturn ‘1’
Input/Output Name Type DescriptionO Speech Array Array of int Array containing last speech sample recorded by
sound cardO Procedure
Successint Returns 1 for success and 0 for failure
Speaker Verification for Smart Cards 57
Software Design Description
5.1.7 Speaker Verification
Data
Processing
As mentioned in the previous section, the code for the speaker verification methods is contained within a library file. Since we have no access to actual algorithm for these methods there are no algorithms for this section.
Speaker Verification for Smart Cards 58
Software Design Description
5.1.8 GUI
Data
The Graphical User Interface uses the variables described in the table below to display them to the user.
Name Description TypeUser Name Name of the user StringSpeech Sample The user’s voice input into the
sound card.Array of int
Text for Verification Text spoken by user on each attempt of verification
String
Picture File Name File name for user Picture file StringDate of Birth Date of birth of user Integers (ddmmyy)Street Street in which user lives StringSuburb Suburb in which user lives StringWork Phone Number Phone number of user’s work
placeIntegers
Home Phone Number Phone number to user’s home IntegersUser Access Level of access for user to
system.String
Table 7 - GUI Data
Processing
Procedure Enter Card
Wait for ASEGetCardStatus interrupt from the window managerIf chCardPresence is true
Destroy enter card prompt windowPrompt user for choice of verification or training windowIf training window is requested
Display training graphical user interfaceElse
Display verification graphical user interface
Inputs/Outputs Name Type DescriptionI Card present Int The value 1 indicates that a card is present in
the card reader, and 0 is the card reader is waiting for a card.
Procedure Display Results
Obtain results from speech verificationIf results is customer
Display “user accepted”Else
Display “user access denied”
Inputs/OutputsName Type Description
I Model Int Indicates if the cardholder is a customer or an imposter
Speaker Verification for Smart Cards 59
Software Design Description
Procedure Display Waveform
Initialise sampling variablesInitialise sound card, set up sample rate, sample resolution and bufferSet the coordinates for the displaying the waveform on the GUIInitialize the drawing variablesWait for voice inputWhile samples are present
Check magnitude of sampleIf sample OK
Draw sample to GUICopy sample to a temp file
Inputs/Outputs Name Type DescriptionI Speech sample Int The coordinates of the speech sample
Procedure Display Personal
Open fileLoad photo from fileRead textDisplay text as Name, Address phone numbers, etc.
Inputs/Outputs Name Type DescriptionI Filename StringI Info Text This is the information obtained about the
user from the database.
Speaker Verification for Smart Cards 60
Software Design Description
5.1.9 Verification Processing
Data
The Verification uses the variables described in the table below to perform this process.
Name Description TypeState Current state of the Smart Card
inserted.byte
Verification Certificate Standard certificate showing that this is a project Smart Card with valid data contained on it.
bits
ID Pointer to database record. bytesUser Object Storage object containing a
public variable for each field of the database. Include: ID, name, address, picture, decryption, dob, phone numbers and access level
Text for Verification Text spoken by user on each attempt of verification
String
Speech Sample The user’s voice input into the sound card.
Array of int
Speech Model result The method returns a success/fail result:‘1’ for success‘0’ for failure
int
User Name Name of the user StringPicture File Name File name for user Picture file StringDate of Birth Date of birth of user Integers (ddmmyy)Street Street in which user lives StringSuburb Suburb in which user lives StringWork Phone Number Phone number of user’s work
placeIntegers
Home Phone Number Phone number to user’s home IntegersUser Access Level of access for user to
system.String
Table 8 - Verification Processing Data
Speaker Verification for Smart Cards 61
Software Design Description
Procedure Verification
Power on cardRead card statusPerform mutual authenticationIf authentication is not ok
Display error messageExit program
ElseRead card dataIf data is not ok
Display error messageExit program
ElseRead data from databaseDecrypt user speech modelInitialise sound cardGet speech sample from userCall speaker verification procedureIf user is imposter
Display user invalidExit program
ElseDisplay user results
Clean up
Inputs/Outputs Name Type descriptionO Return Value int The method returns a success/fail
result:‘1’ for success‘0’ for failure
O Error Message String Informs the user what type of erro has occurred.
Procedure Initialisation
Initialise Data VariablesInitialise GUI Initialise Smart Card ReaderInitialise Smart Card Interrupts
Inputs/Outputs Name Type Description(none)
Procedure SmartCardInserted
Call VerifyUser
Inputs/Outputs Name Type Description(none)
Procedure SpeechSample
Call GetSpeechSample
Inputs/Outputs Name Type Description(none)
Speaker Verification for Smart Cards 62
Software Design Description
5.1.10 Training Processing
Data
The training mode uses the following variables described in the table below to perform this process.
Name Description TypeState Current state of the Smart Card
inserted.byte
Verification Certificate Standard certificate showing that this is a project Smart Card with valid data contained on it.
bits
Text for Verification Text spoken by the user to create the model that will be used for the verification process.
String
Speech Sample The users voice input into the sound card.
Array of int
Speech Model created result The method returns a success/fail result:‘1’ for success‘0’ for failure
int
ID Pointer to database record. bytesUser Name Name of the user StringPicture File Name File name for user Picture file StringDate of Birth Date of birth of user Integers (ddmmyy)Street Street in which user lives StringSuburb Suburb in which user lives StringWork Phone Number Phone number of user’s work
placeIntegers
Home Phone Number Phone number to user’s home Integers
Table 9 - Training Processing Data
Speaker Verification for Smart Cards 63
Software Design Description
Procedure Training
Power on cardRead card statusIf authentication is not ok
Display error messageExit program
ElseRead card dataIf data is not ok
Display error messageExit program
ElseGet users informationDisplay speech sentenceInitialise sound cardLoop four times
Get speech samplesCreate user speech modelIf speech model is not ok
Display error messageExit programElse
Store user info in databaseEncrypt user speech modelStore data card
Clean up
Inputs/Outputs Name Type descriptionO Return Value int The method returns a success/fail
result:‘1’ for success‘0’ for failure
O Error Message String Informs the user what type of erro has occurred.
Procedure Initialisation
Initialise Data VariablesInitialise GUI Initialise Smart Card ReaderInitialise Smart Card Interrupts
Inputs/Outputs Name Type Description(none)
Procedure SmartCardInserted
Call Training
Inputs/Outputs Name Type Description(none)
Speaker Verification for Smart Cards 64
Software Design Description
Procedure SpeechSample
Call GetSpeechSample
Inputs/Outputs Name Type Description(none)
Procedure Authentication
Call Authenticate
Inputs/Outputs Name Type Description(none)
Procedure ProcessUserInput
Get User InputCopy input to appropriate variables in UserObject
Inputs/Outputs Name Type Description(none)
Procedure CreateSpeechModel
Call TrainSpkrModelDisplay Success/Fail Result
Inputs/Outputs Name Type Description(none)
Speaker Verification for Smart Cards 65
Software Design Description
History of SDD:
Date Version No. ChangesJuly 7th 1998 1.000000 Did a skeleton outline of SDD
with Smart Card entity described and included introduction
July 10th 1998 1.000001 Completed entries for all entities having done one entity originally for approval by supervisors
July 13th 1998 1.000002 Updated interfaces section to have tables reflecting inputs and outputs for all functions instead of casual description
July 15th 1998 1.000003 Updated detailed description section to have consistent formatting on all function algorithms
July 20th 1998 2.000000 Added picture of GUI for verification
July 24th 1998 2.000001 Added diagrams for module description
July 25th 1998 2.000002 Changed the name of the project and all other references to Speaker Verification for Smart Cards instead of Speaker Recognition for Smart Cards
July 26th 1998 2.000003 Added extra screen shots to show all processes of the GUI
July 28th 1998 2.000004 Updated document to show how the SDD satisfies the SRS.
July 28th 1998 2.000005 Final checked and approved copy
Speaker Verification for Smart Cards 66