test2

University of South Australia
Computer Systems Engineering Project

Speaker Verification for Smart Cards

SDD - Software Design Description

Version 2.000005

July 28th, 1998

Project Group: Cecilia Berry 9506009u
Glen Olafsen 9505995d
Peter 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


Table of Contents
1 INTRODUCTION.................................................................................................................................6
1.1 PURPOSE.............................................................................................................................................6
1.2 SCOPE.................................................................................................................................................6
1.3 DEFINITIONS AND ACRONYMS.................................................................................................................7
1.4 REFERENCES........................................................................................................................................8
2 DECOMPOSITION DESCRIPTION...............................................................................................9
2.1 SYSTEM ENTITIES...............................................................................................................................12
2.1.1 Smart Card Operations...........................................................................................................12
2.1.2 Smart Card Data.....................................................................................................................13
2.1.3 Database Operations..............................................................................................................14
2.1.4 Database Data........................................................................................................................15
2.1.5 Encryption...............................................................................................................................16
2.1.6 Sound Card.............................................................................................................................17
2.1.7 Speaker Verification...............................................................................................................18
2.1.8 GUI.........................................................................................................................................19
2.1.9 Verification Processing..........................................................................................................20
2.1.10 Training Processing..............................................................................................................21
3 DEPENDENCY DESCRIPTION......................................................................................................22
3.1 SYSTEM ENTITIES...............................................................................................................................23
3.1.2 Smart Card Data.....................................................................................................................24
3.1.4 Database Data........................................................................................................................26
3.1.5 Encryption...............................................................................................................................27
3.1.6 Sound Card.............................................................................................................................28
3.1.8 GUI.........................................................................................................................................30
3.1.10 Training Processing .............................................................................................................32
4 INTERFACE DESCRIPTION..........................................................................................................33
4.1 SYSTEM ENTITIES ..............................................................................................................................36
4.1.1 Smart Card Data.....................................................................................................................36
4.1.3 Database Data........................................................................................................................38
4.1.5 Encryption...............................................................................................................................41
4.1.6 Sound card..............................................................................................................................42
4.1.7 Graphical User Interface........................................................................................................43
4.1.9 Verification Processing .......................................................................................................47
4.1.10 Training Processing..............................................................................................................48
5 DETAILED DESIGN DESCRIPTION.............................................................................................49
5.1 SYSTEM ENTITIES...............................................................................................................................49
5.1.2 Smart Card Data.....................................................................................................................51
5.1.4 Database Data........................................................................................................................55
5.1.5 Encryption...............................................................................................................................56
5.1.6 Sound Card.............................................................................................................................58
5.1.8 GUI.........................................................................................................................................60
5.1.10 Training Processing .............................................................................................................64



Figures
FIGURE 1 - VERIFICATION PROCEDURE...................................................................................10

FIGURE 2 - TRAINING PROCEDURE.............................................................................................11

FIGURE 3 - SMART CARD MODULE DESIGN.............................................................................12

FIGURE 4 - DATABASE OPERATIONS MODULE DESIGN.......................................................14

FIGURE 5 - ENCRYPTION MODULE DESIGN..............................................................................16

FIGURE 6 - SOUND CARD MODULE DESIGN..............................................................................17

FIGURE 7 - SPEAKER VERIFICATION MODULE DESIGN.......................................................18

FIGURE 8 - GUI MODULE DESIGN.................................................................................................19

FIGURE 9 - VERIFICATION SUBORDINATES.............................................................................20

FIGURE 10 - TRAINING SUBORDINATES.....................................................................................21

FIGURE 11: SMART CARD MODULE SEQUENCING.................................................................23

FIGURE 12 - DATA FLOW DIAGRAM FOR VERIFICATION MODE......................................34

FIGURE 13 - DATA FLOW DIAGRAM FOR TRAINING MODE................................................35

FIGURE 14 - GREETING TO USER..................................................................................................43

FIGURE 15 - MODE SELECTION.....................................................................................................43

FIGURE 16 - VERIFICATION MODE..............................................................................................44

FIGURE 17 - TRAINING MODE........................................................................................................44

FIGURE 18: MEMORY MAP FOR MEMORY PROTECTED SMART CARDS........................51

Tables
TABLE 1 - SMART CARD OPERATIONS DATA...........................................................................49

TABLE 2 - SMART CARD DATA......................................................................................................51

TABLE 3 - DATABASE OPERATIONS DATA................................................................................52

TABLE 4: DATABASE FIELDS..........................................................................................................55

TABLE 5 - ENCRYPTION DATA.......................................................................................................56

TABLE 6 - SOUND CARD DATA.......................................................................................................58

TABLE 7 - GUI DATA..........................................................................................................................60

TABLE 8 - VERIFICATION PROCESSING DATA........................................................................62



TABLE 9 - TRAINING PROCESSING DATA..................................................................................64



1 Introduction
This 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.



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



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



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 Operations
2. Smart Card Data
3. Database Operations
4. Database Data
5. Encryption
6. Sound Card
7. Speaker Verification
8. GUI
9. Verification Processing
10. 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.



S tart

P o w er O n C ard

R e ad C a rd S tatu s

A u th e n tic atio n
Sm art C ard
O p e ratio n s
an d D a ta

A u th e n c ti-
c atio n O K ? N O

YES

R e ad C ard D a ta

D ata O K ?
N O
YES

D atab ase
O p e r a tio n s R e ad D ata F ro m D atab as e
an d D a ta

E n c ryp tio n
D e crypt U se r S pe ec h M o de l

In itia lis e S o u n d C a rd
Sound C ard

G e t S p e e c h S am p le fro m
U ser

S p e a k e r V e r i fi c a ti o n C all S p e ak e r V e rific atio n
P ro c e du re

N O
Is U s e r
D is p lay U s e r in valid
A u th e n tic ?

YES

G U I D is p lay R e s u lts

C le an u p

F in is h D is p lay E rro r

Figure 1 - Verification Procedure



S ta rt

P o w e r O n C a rd

R e a d C a rd S ta tu s

S m a rt C a rd A u th e n tic a tio n
O p e r a t io n s
a n d D a ta

A u th e n c ti-
c a tio n O K ? N O

YES

R e a d C a rd D a ta

D a ta O K ?
N O

YES

G e t U s e r In f o r m a tio n
G U I
D is p la y S p e e c h
S e n te n c e

In itia lis e S o u n d C a r d

S ou n d C ard
G e t S p e e c h S a m p le

Looped 4 N O
tim e s ?

YES

Speaker C re a te U s e r S p e e c h
V e r ific a tio n M odel

Speech M odel
O K? N O

YES

D a ta b a s e
O p e r a tio n S to re D a ta in D a ta b a s e
a n d D a ta

E n cryp t E n c ry p t S p e e c h M o d e l

S m art C a rd
O p e r a tio n s S to re D a ta o n C a rd
a n d D a ta

C le a n u p

F in is h D is p la y E rro r M e s s a g e

Figure 2 - Training Procedure



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
S m a r tC a r d s

In itia lisa tio n
C ar d F u n c tio n ality

Tu rn o n R e ade r T u rn o n In te rru pts
A u th e n tica tio n
R e a d D a ta

C h e c k I n it ia l
C a rd S ta tu s

W r it e D a t a

Figure 3 - Smart Card Module Design



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



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

D a ta b a s e
O p e r a tio n s

C onnect W r it e

D is c o n n e c t U p d a te

S earc h R ead

Figure 4 - Database Operations Module Design



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.



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.

E n c r y p tio n

C r yp to g r ap h y F ile O p e r atio n s

G e n e r a te C ry p t R e a d D a ta W r it e D a t a

Figure 5 - Encryption Module Design



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

S o und C a rd

I n it ia lis e R e t r ie v e D a t a

S o u n d C ard In te rru p ts

Figure 6 - Sound Card Module Design



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

Speaker
R e c o g n itio n

S peech M odel
R e c o g n i t io n
G e n e r a t io n

Figure 7 - Speaker Verification Module Design



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.

G U I

C ard P res en t D i s p la y R e s u lt s D is p l a y W a v e f o r m D is p la y P e r s o n a l

Figure 8 - GUI Module Design



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 reader
The following diagram shows how these events are handled by the entity.

V e r if ic a t io n P r o c e s s in g

G U I H a n d le r S ou nd C ard
S m a r t C a r d H a n d le r
H a n d le r

E vent Event I n te r ru p t I n te r ru p t In te rr u p t

C a n c e l B u tto n S p e e c h S a m p le S m art C ard S m art C ard
I n it i a l is a t io n
P ressed R ec ord ed I n s e r te d R em oved

P ro c ess S p eec h
S a m p le

E x it P r o c e d u r e V e r if i c a t io n P r o c e d u r e

I n it i a l is a t io n P r o c e d u r e E x it P r o c e d u r e

Figure 9 - Verification Subordinates



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.

T r a in in g P r o c e s s in g

G U I H a n d le r S o und C ard
S m a r t C a r d H a n d le r
H a n d le r

Event Event I n te rr u p t I n te r r u p t In te r r u p t

S p e e c h S a m p le S m art C ard S m art C ard
I n i t ia l is a t io n R ec o rd ed In s e r te d R em oved

B u tto n P r e s s e d

I n it i a l is a t io n P r o c e d u r e P roc ess S p eec h
S a m p le

A u t h e n t i c a t io n P r o c e d u r e

E x it P r o c e d u r e

P roc ess U ser
E x it P r o c e d u r e In p u t C r e a te U s e r M o d e l

Figure 10 - Training Subordinates



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.



3.1 System Entities


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.

S m a r t C a r d M o d u le
Tu rn O n
R eader D ependent upon W r ite to C a rd
A u t h e n t ic a t io n s u c c e s s

Tu rn O n
In iti a li za ti o n In te r r u p ts C a r d F u n c t io n a lit y A u t h e n t ic a t io n
In te rru pts

D ep en dent upo n
A u t h e n t ic a t i o n s u c c e s s R e a d fro m
C h e ck F or C ard
C a rd In R e ade r Y es

Figure 11: Smart Card Module Sequencing

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.




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.




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



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.



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.



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




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.



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.




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.




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.



4 Interface Description
The 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.



a sm art c ard
I n p u t v o ic e

Sound S m art
C ard C ard

c a r d id

P o in t e r t o u s e r s d a t a

D .B . D a ta b a s e

U s e r in f r o m a t io n
D e c r y p t io n U ser
key in f r o m a t io n

T e m p d ir e c t o r y
F i le p o in t e r
E n c ry p to s p e e c h m o d e l
t io n

S peec h m odel

S peech
S a m p le S peech
V e r if .

R e s u lt

S peech
S a m p le U s e r p e r s o n a l d e t a i ls
G UI

U p d a t e d i s p la y

G r a p h ic a l d i s p la y

Figure 12 - Data flow diagram for verification mode



I n p u t v o ic e

Sound
C ard

a sm art c ard

S peech
S a m p le

S m art
C ard
T e m p d ir e c t o r y
D e c r y p t io n
four key c a r d id
S peec h
S a m p le s

E n c r y p t io n U ser
S peec h E nc ryp key in f r o m a t io n
D .B .
V e r if . S peec h t io n F il e p o in t e r
m odel to s p e e c h
m odel

D a ta b a s e

U s e r d e t a i ls

G UI

U p d a t e d is p l a y
S peec h
S a m p le
G r a p h i c a l d i s p la y U ser
personal
d e t a i ls

Figure 13 - Data flow diagram for training mode



4.1 System Entities


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.

Interfaces
This entity is one that is used to describe the data storage on the Smart Cards, and hence has no
interfaces.


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.

Interfaces
From 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 Description
O Return Value int The method returns a success/fail result:
‘1’ for success
‘0’ for failure

Procedure TurnOnInterrupts

int TurnOnInterrupts(void);

O Return Value Int The method returns a success/fail result:
‘1’ for success
‘0’ for failure



Procedure CheckInitialCard

int CheckInitialCard(void);

O Return Value Int Returns ‘1’ if there is a
card in the reader, ‘0’ if
not.

Card Functionality

Procedure Authentication

int Authentication(void);

O Return Value Int Returns ‘1’ if authentication is successful, returns ‘0’ if
not.

Procedure ReadCardData

int ReadCardData(int *CardID, CString *UserName, DWORD *DecryptKey);

O CardID int The Card Identification number
O UserName String The name of owner of the card
O DecryptKey DWORD The decryption key for the database
O 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);

I CardID int The Card Identification number
I UserName String The name of owner of the card
I DecryptKey DWORD The decryption key for the database
O Return Value int Returns a success/fail result:
‘1’ if data read successfully
‘0’ if not.



4.1.3 Database Data

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.

Interfaces
The 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.


Function
Following 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 database
2. Searches table for ID matching card currently inserted
3. Reads entire row and returns the values in each field separately
4. Write entire row.
5. Update a single field or multiple fields in a specific row
6. Disconnect from database

All of these capabilities are built into individual functions, which are publicly accessible.

Interfaces
As 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 Description
I Database name DWORD Table file name
O 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

int SearchID(int UserID, int *Recordno, CString *Message);

I User ID from Smart Integer Random Integer used as
Card primary key to the
database
failure
O Record no. Integer Pointer to the record in
the database
corresponding to the
user
Or
Message String Error message for no
record with that User ID

Procedure ReadRow

int ReadRow(int Recordno, UserInfo *user)

I Record no. Integer Pointer to the user’s
record in the table
failure
O User object Object with public The User object is a data
• Name variables storage class into which
• Encryption key all of the user’s details
• User’s text are read from the
• User’s Speech database. The use of an
pattern object makes passing of
• Picture File information around the
name system cleaner and more
• DOB efficient.
• Street
• Suburb
• Work Phone
Number
• Home Phone
Number
• User Access
Level



Procedure WriteRow

int WriteRow(Userinfo user)

I User Object Data Storage Object Object containing public
variables with a users
personal information
stored in each.
failure

Procedure UpdateRow

int UpdateRow(Userinfo user,int Recordno);

stored in each.
I Record no. Integer Pointer to the record
number in the table for
the user.
failure

Procedure Disconnect

int Disconnect(void);

failure



4.1.5 Encryption

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

Interfaces
Before 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);

O 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);

I 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.



4.1.6 Sound card

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

Interfaces
The 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);

O Procedure int Returns 1 for success and 0 for failure
Success

Procedure InitSoundInterrupts

int InitSoundInterrupts(void);

Success

Procedure GetSpeechSample

int GetSpeechSample(int Speech[]);

O Speech Array Array of int Array containing last speech sample recorded by
sound card
Success



4.1.7 Graphical User Interface

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

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.



Figure 16 - Verification Mode

Figure 17 - Training Mode

Interfaces
The 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



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 Description
‘1’ for success
‘0’ for failure

Procedure Display Results

int DisplayResults(void);

Name Type Description
Inputs/Outputs
‘1’ for success
‘0’ for failure

Procedure Display Waveform

int DisplayWaveform(int *SpeechSample);

I Speech sample int * The coordinates of the speech sample
‘1’ for success
‘0’ for failure

Procedure Display Personal

int DisplayPersonal(UserInfo info);

stored in each.
O Return Value int The method returns a
success/fail result:
‘1’ for success
‘0’ for failure




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.

Interfaces
The 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 Description
I spkrID char * The name of the user
I allFileNames char * [] Array of filenames
containing the speech
samples
I numFiles int The number of filenames
listed in the above array
‘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 Description
I fileName char * The name of the file
containing the speech
sample
I spkrID char * The name of the user
‘1’ for success
‘0’ for failure




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);

O 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);

(none)

Procedure SmartCardInserted

void SmartCardInserted(void);

(none)

Procedure SpeechSample

void SpeechSample(void);

(none)




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 user
int TrainUser(CString *ErrorMessage);

Inputs/Outputs Name Type description
O 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);

(none)

Procedure SmartCardInserted
void SmartCardInserted(void);

(none)

Procedure SpeechSample
void SpeechSample(void);

(none)

Procedure Authentication
void Authentication(void);

(none)

Procedure ProcessUserInput
void ProcessUserInput(void);

(none)

Procedure CreateSpeechModel
void CreateSpeechModel(void);

(none)



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


Data
The following data will be used by this entity having taken it from the Smart Card.

Name Description Size
Password For use with Memory Protected 8 bytes
Smart Cards, needed to read and
write from card.
State Current state of the Smart Card 1 byte
inserted.
Verification Certificate Standard certificate showing that 128 bits
this is a project Smart Card with
valid data contained on it.
ID Pointer to database record. 4 bytes
Name String for user name. 100 bytes
Decryption Key Decryption Key to the encrypted 128 bits
speech file stored on the terminal.

Table 1 - Smart Card Operations Data

Processing
Initialization

Procedure TurnOnReader

Call ASEReaderOpenByName

‘1’ for success
‘0’ for failure

Procedure TurnOnInterrupts

Call ASEReaderSetMessage

‘1’ for success
‘0’ for failure


test2

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Viewers also liked

Viewers also liked (9)

Similar to test2

Similar to test2 (20)

test2