Voice as a

Password
Security & Risk Report

Team 5 Security Team

SIT302 Project Delivery

Unit Chair Dr. Greg Bowtell

Team 5 | Voice as a Password 0

Contents

1. Executive Summary 2
1.1 Introduction 2
1.2 Purpose 2
1.3 Scope of Security & Risk 2
1.4 Execution of Security & Risk Report 2
2. Risk Profile 3
2.1 Risk Assessment 3
2.2 Source Code Check 4
2.3 Recommended Security Algorithms 5
2.4 Recommended Security Protocols 6
2.5 Risk Maturity Assessment 7
2.6 High Level Security Solutions Proposal 8

Team 5 | Voice as a Password 1

 1. Executive Summary
1.1 Introduction
Client Dr Mohamed Abdelrazaek approached Team 5 with developing an application that will allow
the use of voice as a password. This application was required to authenticate a user with another
application or system by the methodology of voice.
Team 5 aims to develop a voice authentication library that can be implemented into various
applications, so that the developers can simplify the authentication method while still offering
secured access to their applications.
Security of authentication is a vital part in measuring the success of this application and Team 5
aims to apply contemporary best practices of security governance and controls.

1.2 Purpose
The purpose of this report is to support the project by investigating and assessing the security and
risks involved as part of the design phase to ensure that implementation and operation of the
application complies with all security requirements in addressing key risk factors.
The report also ensures valuable communication of information to key stakeholders in order to
establish trust with Team 5 and the ongoing development of the project.

1.3 Scope of Security & Risk

The Security and Risk Report must support the project vision as stated in the Project Proposal
and the ability to ensure the fundamentals of Confidentiality, Integrity and Availability are
integrated within the entire project.
Key application requirements that security must support:
a) End user must be able to use voice as a password, so that they can log in to public
services securely;
b) Application should be able to uniquely identify human voice minimising risks of hacking or
imitation; and
c) Application must be able to extract, transmit and store data securely.

1.4 Execution of Security & Risk Report

The steps taken within this report to support the purpose:
a) Risks will be identified and assessed to gain an understanding of the applications critical
and vulnerable aspects;
b) Security and vulnerability checks of design phase activities;
c) Recommended security algorithms and protocols to use for security design and
development;
d) Maturity assessment to understand the current phases security and risk status as well as
identify areas of improvement; and
e) High level security solutions (including standards, procedures, guidelines and controls)
proposed to support phase 2 of the project that address identified risks.

Team 5 | Voice as a Password 2

2. Risk Profile
2.1 Risk Assessment

Risk Grading Legend

1 - Low
Unauthorised Database Access
4 2 - Minor
An unsecure database can easily be accessed by attackers. Users
voice data could be stolen which threatens their privacy and 3 - Moderate
compromises the login system. The database will need to be encrypted 4 - Major
to ensure the data is kept secure.
5 - Critical
Voice Impersonation Attack
5
Voice authentication systems can be vulnerable to voice impersonation
attacks through a cloned recording or synthesized speech. Users could
be vulnerable to social engineering attempting to obtain a sample of
their voice to be used to access their account.

Noisy Environment
2
Background noise could affect the accuracy of recognising users voices
when attempting to log in, it could falsely deny them access. If a user
first sets their "voice password" in a noisy environment, they may not be
able to get in later as the recording may have picked up that
background noise. In order to prevent this the application needs to filter
out background noise.

Word Recognition Failure

3
Requiring the users to say random words to log in is an important
aspect of this application's security. It helps to guard against using a
voice recording of a user to gain access. If the application does not
correctly identify words the system will be much less secure.

Data Storage Failure

2
The data in the database could be lost if there is a disaster where the
data is being kept; there could be a fire or flood. There could just be a
hardware failure, or it could simply be lost. Backups will be required.
This also applies to source code during development.

Data Disclosure
2
Data access should be limited to those who absolutely need it and are
trusted to not disclose sensitive data.

Source Code Vulnerabilities

3
The program could be vulnerable to buffer overflows, non-validated
input, and bugs. These can all compromise the security of the system if
exploited.

Team 5 | Voice as a Password 3

2.2 Source Code Check

One of the key security fundamentals to developing an application is ensuring that the source code
used to develop is secure and contains no vulnerabilities. This will need to be reviewed at each
phase of the project.

Name Total % of Lines of Commented Whitespace Potentially Potentially

Lines Total Code Lines unsafe unsafe
Flags Code

Resources.Designer.cs 63 3.633 32 22 8 0 0

Settings.Designer.cs 26 1.499 12 8 5 0 0

XMLFunctions.cs 11 0.634 7 0 4 0 0

Database.cs 125 7.209 81 19 25 0 0

frmMain.cs 583 33.622 451 59 73 0 0

UserRecord.cs 19 1.096 14 1 4 0 0

speechRecognition.cs 49 2.826 41 3 5 0 0

sentenceGenerator.cs 52 2.999 43 4 5 0 0

frmMain.Designer.cs 467 26.932 348 45 6 0 0

Program.cs 22 1.269 18 3 1 0 0

XMLFunctions.cs 100 5.767 12 82 6 0 0

audioCapture.cs 169 9.746 118 28 23 0 0

projectOxford.cs 12 0.692 11 0 1 0 0

Team 5 | Voice as a Password 4

2.3 Recommended Security Algorithms
The following is a list of all the security algorithms which are recommended by Team 5s Security
Team. Future standards and procedures documentation will be provided to ensure that all
implementation will comply with a standard. This is a guide to assist the development team to
ensure a secure foundation is established.

MD5:
The MD5 algorithm is a widely used hash function producing a 128-bit hash value. Although MD5
was initially designed to be used as a cryptographic hash function, it has been found to suffer from
extensive vulnerabilities.
Relation: MD5 use hash function, so it is easier to implement in C#, which is what the program
uses. MD5 is extremely vulnerable, but we can still use MD5 to checksum data integrity.
RSA:
RSA is one of the first practical public-key cryptosystems and is widely used for secure data
transmission. In such a cryptosystem, the encryption key is public and differs from the decryption
key which is kept secret. In RSA, this asymmetry is based on the practical difficulty of factoring the
product of two large prime numbers, the factoring problem.
Relation: Compared with other algorithm, RSA is a slow way for encryption, but very safe. For
voice data of bulk encryption-decryption operations, it is a higher speed to ensure voice data is
safe for transmission and using. It is recommended to use RSA for safe key exchange.
AES:
The Advanced Encryption Standard (AES), also known by its original name Rijndael is a
specification for the encryption of electronic data established by the U.S. National Institute of
Standards and Technology (NIST) in 2001. For AES, NIST selected three members of the Rijndael
family, each with a block size of 128 bits, but three different key lengths: 128, 192 and 256 bits.
AES has been adopted by the U.S. government and is now used worldwide. It supersedes the Data
Encryption Standard (DES), which was published in 1977. The algorithm described by AES is a
symmetric-key algorithm, meaning the same key is used for both encrypting and decrypting the
data. AES is available in many different encryption packages, and is the first (and only) publicly
accessible cipher approved by the National Security Agency (NSA) for top-secret information when
used in an NSA approved cryptographic module.
Relation: This is a global and safe way for encryption, it can encrypt many kinds of data, such as
message, video and voice. It is recommended to use AES to encrypt the actual data.

Recommendation:
AES should be used alongside RSA to ensure secure data transmission. Since AES is symmetric
encryption (only uses one key for encrypting and decrypting), it is vulnerable during key exchange.
RSA uses two different keys for encryption and decryption, one public and one private. Using RSA
for key exchange and AES to encrypt the actual data will enable data to stay secure. MD5 can be
used to check whether the data is what it is supposed to be, ensuring data integrity.

Team 5 | Voice as a Password 5

2.4 Recommended Security Protocols
The following is a list of all the security protocols which are recommended by Team 5s Security
Team. Future standards and procedures documentation will be provided to ensure that all
implementation will comply with a standard. This is a guide to assist the development team to
ensure a secure foundation is established.

VoIP:
Voice over Internet Protocol (Voice over IP, VoIP and IP telephony) is a methodology and group of
technologies for the delivery of voice communications and multimedia sessions over Internet
Protocol (IP) networks, such as the Internet. The terms Internet telephony, broadband telephony,
and broadband phone service specifically refer to the provisioning of communications services
(voice, fax, SMS, voice messaging) over the public Internet, rather than via the public switched
telephone network (PSTN).
Relation: VoIP is available on many smartphones, personal computers, and on Internet access
devices. Voice password needs VoIP to transmit information and based on the VoIP is easier to
achieve voice service.

SRTP:
The Secure Real-time Transport Protocol (or SRTP) defines a profile of RTP (Real-time Transport
Protocol), intended to provide encryption, message authentication and integrity, and replay
protection to the RTP data in both unicast and multicast applications.
ZRTP:
ZRTP (composed of Z and Real-time Transport Protocol) is a cryptographic key-agreement
protocol to negotiate the keys for encryption between two end points in a Voice over Internet
Protocol (VoIP) phone telephony call based on the Real-time Transport Protocol. It uses Diffie
Hellman key exchange and the Secure Real-time Transport Protocol (SRTP) for encryption.
Relation: The VoIP needs encryption to transmit and SRTP is used in real-time transport for
encryption and ensure the message authentication and integrity. ZRTP, can be uses for encryption
between user login and reply.

Team 5 | Voice as a Password 6

2.5 Risk Maturity Assessment
The maturity assessment is not a pass or fail test. It is to gauge and understand the maturity of the
specific risk of the project. This will allow the project manager to view the status of each area and
plan for improvement. This improvement may be the re-allocation of resources and the re-
configuring of design and/or development. Periodical maturity assessments will be required at each
phase of the project to ensure progressive growth.

LEGEND

1: Unmanaged - indicates that the team is either unaware of the risk/issue or has taken no steps to address
this risk or issue.

2: Aware - indicates that the team has an awareness of the risk/issue but there is little practical evidence of
action.

3: Formative - indicates that the team is actively addressing a particular risk or issue. There is evidence of a
planned approach, even if it is not fully implemented.

4: Operational - indicates that the team has completed implementation of planned initiatives in regard to the
risk issue and that those initiatives are operation to a reasonable standard.

5: Proactive - our ultimate goal where the team has a plan, is operating to address the risk/issue and is future
proofing risks by having maintenance, patching and review schedules in place.

Risk Test Grading

Unauthorised Database Encryption algorithms have been researched. Text 3

Access encryption has been implemented.

Voice Impersonation Attack A recording of a users voice produces a successful 1

match.

Noisy Environment Attempting to match a users voice with talking in the 1

background was unsuccessful.

Word Recognition Failure Word recognition is fairly accurate. However similar 3

sounding words can be confused. Clear words are being
chosen as part of the random word pool.

Data Storage Failure Backup of source code is on github. The program was 2
deleted and successfully restored from the backup. No
database backup plans.

Data Disclosure It has not been decided who has access to the data and if 1
they are trusted.

Source Code Vulnerabilities The code has been tested using VisualCodeGrepper. The 3
program is being tested for errors as development
progresses.

Team 5 | Voice as a Password 7

2.6 High Level Security Solutions Proposal
The security solutions proposed may be amended during the progression of the project as new
risks or project changes arise. These solutions are a guide to inform key stakeholders of the
projects roadmap regarding security and risk.

The following security deliverables are required for the next phase of the project with priority levels,
duration of work and prerequisites:

ID Deliverable Description Priority Duration Prerequisite

1 Security Plan A plan which details the highest critical risks and HIGH 2 weeks
the method to address it with a structured
approach

2 Roles and A document containing each members role in MEDIUM 1 week

Responsibilities the team and their responsibilities within the
project so there is a high level of accountability

3 Security Controls A document which lists all the controls required MEDIUM 2 weeks 1
and mentioned in the Security Plan to protect
and prevent the system from threats or failure

4 Security Standards An overarching security standards document MEDIUM 1 week 1

which will ensure that the most current and
secure encryption, algorithms, protocols and
methodology is used. Development team must
comply with these standards.

5 Risk Maturity Review how the projects risks have been LOW 1 week 1, 2, 3, 4
Assessment addressed and their maturity levels.
Phase 2

6 ISMS audit An audit and report to review the performance of LOW 1 week 2, 3, 4
deliverables 2, 3 and 4. A metric system should
be established and periodical auditing set out in
a future security policy.

7 Security Policy (If required) This should detail all the policies LOW 1 week All above
that the developing and support team should
comply with regarding security.

Team 5 | Voice as a Password 8