CRYPTOGRAPHY

DLBCSCT01-01
CRYPTOGRAPHY
 MASTHEAD

Publisher:
IU Internationale Hochschule GmbH
IU International University of Applied Sciences
Juri-Gagarin-Ring 152
D-99084 Erfurt

Mailing address:
Albert-Proeller-Straße 15-19
D-86675 Buchdorf
[email protected]
www.iu.de

DLBCSCT01-01
Version No.: 001-2024-0410

Prof. Dr. Ralf Kneuper

© 2024 IU Internationale Hochschule GmbH

This course book is protected by copyright. All rights reserved.
This course book may not be reproduced and/or electronically edited, duplicated, or dis-
tributed in any kind of form without written permission by the IU Internationale Hoch-
schule GmbH.
The authors/publishers have identified the authors and sources of all graphics to the best
of their abilities. However, if any erroneous information has been provided, please notify
us accordingly.

2
 TABLE OF CONTENTS
CRYPTOGRAPHY

Introduction
Signposts Throughout the Course Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Basic Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Further Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Learning Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Unit 1
Protection Goals, Vulnerabilities and Threats 11

1.1 Protection Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.2 Weaknesses and Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Unit 2
Foundations of Cryptology and its Core Components 19

2.1 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2 Symmetrical Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3 Asymmetric Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.4 One-way Functions and Cryptographic Hash Functions . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Unit 3
Basic Cryptographic Applications 39

3.1 Key exchange and Hybrid Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.2 Digital Signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.3 Message Authentication Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.4 Steganographic Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Unit 4
Authentication 53

4.1 Passwords and public key certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.2 Challenge-Response and Zero-Knowledge Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.3 Biometric Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.4 Authentication in Distributed Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.5 Identities through smartcards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

3
 Unit 5
Security of Single Computers 71

5.1 Malware and Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

5.2 Some Special Features Concerning Operating Systems . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.3 Web Server Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Unit 6
Security in Communication Networks 83

6.1 Security Problems and Defense Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

6.2 Internet Standards for Communication Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
6.3 Identity and Anonymity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.4 Security in Mobile and Wireless Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Unit 7
Security in E-Commerce 111

7.1 Email Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

7.2 Online Banking and Online Payments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
7.3 Electronic Money . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

Unit 8
Secure Software Development 123

8.1 Threat Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

8.2 Secure Software Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
8.3 Techniques for Secure Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
8.4 Integrating Security Into Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

Appendix
List of References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
List of Tables and Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

4
INTRODUCTION
 WELCOME
SIGNPOSTS THROUGHOUT THE COURSE BOOK

This course book contains the core content for this course. Additional learning materials
can be found on the learning platform, but this course book should form the basis for your
learning.

The content of this course book is divided into units, which are divided further into sec-
tions. Each section contains only one new key concept to allow you to quickly and effi-
ciently add new learning material to your existing knowledge.

At the end of each section of the digital course book, you will find self-check questions.
These questions are designed to help you check whether you have understood the con-
cepts in each section.

For all modules with a final exam, you must complete the knowledge tests on the learning
platform. You will pass the knowledge test for each unit when you answer at least 80% of
the questions correctly.

When you have passed the knowledge tests for all the units, the course is considered fin-
ished and you will be able to register for the final assessment. Please ensure that you com-
plete the evaluation prior to registering for the assessment.

Good luck!

6
 BASIC READING
Paar, C., & Pelzl, J. (2010). Understanding cryptography. A textbook for students and practi-
tioners. Springer. Chapter 1 http://search.ebscohost.com.pxz.iubh.de:8080/login.aspx
?direct=true&db=cat05114a&AN=ihb.48503&site=eds-live&scope=site

Singh, S. (1999). The code book [electronic resource] : the science of secrecy from ancient
Egypt to quantum cryptography (1. ed.). Anchor Books. http://search.ebscohost.com.p
xz.iubh.de:8080/login.aspx?direct=true&db=cat05114a&AN=ihb.52059&site=eds-live&
scope=site

Smart, N. P. (2016). Cryptography made simple. Springer. http://search.ebscohost.com.pxz.

iubh.de:8080/login.aspx?direct=true&db=cat05114a&AN=ihb.52494&site=eds-live&sc
ope=site

7
 FURTHER READING
UNIT 1

Esslinger, B. (2018). Learning and experiencing cryptography with CrypTool and SageMath.
CrypTool Project. Chapter 2

UNIT 2

Esslinger, B. (2018). Learning and experiencing cryptography with CrypTool and SageMath.
CrypTool Project. 116-146.

UNIT 3

Paar, C. & Pelzl, J. (2010). Understanding cryptography. A textbook for students and practi-
tioners. Springer. Chapter 12. http://search.ebscohost.com.pxz.iubh.de:8080/login.as
px?direct=true&db=cat05114a&AN=ihb.48503&site=eds-live&scope=site

UNIT 4

Ferguson, N., Schneier, B., & Kohno, T. (2012). Cryptography engineering. Wiley. Chapter 14

UNIT 5

Alsmadi, I., Burdwell, R., Aleroud, A., Wahbeh, A., Al-Qudah, M., & Al-Omari, A. (2018). Prac-
tical information security. A competency-based education course. Springer. Chapter 2 h
ttp://search.ebscohost.com.pxz.iubh.de:8080/login.aspx?direct=true&db=cat05114a&
AN=ihb.52495&site=eds-live&scope=site

UNIT 6

Alsmadi, I., Burdwell, R., Aleroud, A., Wahbeh, A., Al-Qudah, M., & Al-Omari, A. (2018). Prac-
tical information security. A competency-based education course. Springer. Chapter 6 ht
tp://search.ebscohost.com.pxz.iubh.de:8080/login.aspx?direct=true&db=cat05114a&A
N=ihb.52495&site=eds-live&scope=site

UNIT 7

Whitten, A., & Tygar, J.D. (1999). Why Johnny can’t encrypt: A usability evaluation of PGP
5.0. Proceedings of the 8th USENIX security symposium (pp. 169–183). USENIX Associa-
tion. http://search.ebscohost.com.pxz.iubh.de:8080/login.aspx?direct=true&db=edsb
as&AN=edsbas.85E8DE1D&site=eds-live&scope=site

8
Payment Card Industry Security Standards Council. (2022). Payment card industry data
security standard: Requirements and testing procedures (4.0). Pp. 1-6. https://listings.p
cisecuritystandards.org/documents/PCI-DSS-v4_0.pdf

Nakamoto, S. (2009). Bitcoin: A peer-to-peer electronic cash system. Cryptography Mailing

List. https://bitcoin.org/bitcoin.pdf

UNIT 8

Fredj, O. B., Cheikhrouhou, O., Krichen, M., Hamam, H., & Derhab, A. (2021). An OWASP Top
Ten Driven Survey on Web Application Protection Methods. In J. Garcia-Alfaro, J.
Leneutre, N. Cuppens, & R. Yaich (Eds.), Lecture notes in computer science: Vol: 12528.
Risks and security of internet and systems (pp. 235–252). Springer. http://search.ebscoh
ost.com.pxz.iubh.de:8080/login.aspx?direct=true&db=edsbas&AN=edsbas.8A4D4A38&
site=eds-live&scope=site

Kneuper, R. (2018).

Software processes and life cycle models. An introduction to modelling, using and managing
agile, plan-driven, and hybrid processes. Springer. Chapter 3.11 http://search.ebscohos
t.com.pxz.iubh.de:8080/login.aspx?direct=true&db=cat05114a&AN=ihb.28435&site=e
ds-live&scope=site

9
 LEARNING OBJECTIVES
In this course Cryptography you will get to know the most important technical proce-
dures which help to establish IT security for computer systems and communication net-
works. The focus will be on concepts and measures to defend against threats caused by
unauthorized access "from outside". Defense against the consequences of technical chal-
lenges "from the inside" (for example, due to the failure of components) will not dealt with
in this course.

The methods presented are largely based on concepts and algorithms from the field of
cryptology, which is why the basics of this "science of encryption" will be an important
part of the course. One of the main goals is to introduce the main technical methods and
systems used for establishing IT security in practice, in particular on the internet. For
example, these refer to the confidentiality of communication content or the authenticity
of persons and objects.

10
 UNIT 1
PROTECTION GOALS, VULNERABILITIES
AND THREATS

STUDY GOALS

On completion of this unit, you will be able to ...

– explain the role of technical systems in modern information and communication tech-
nology.
– describe how these systems work together and how they perform their specific individ-
ual tasks.
– discuss the threats that these systems are exposed to.
 1. PROTECTION GOALS, VULNERABILITIES
AND THREATS

Introduction
The aim of this lesson is to create an overview of how individual technical systems interact
in modern IT infrastructure and what threats these systems are exposed to. We will start
with a compilation of the protection goals of information security. This is followed by a
look at possible vulnerabilities and threats that endanger these protection goals. A com-
parison of types of potential attackers and the possible objects of attack shows a variety of
attack scenarios.

1.1 Protection Goals

In general, both resources and data must be protected. No one should have unauthorized
access to a computer and consume computing time, just as no one should be allowed to
access, read or modify data or prevent their proper transmission. To describe this, the fol-
lowing protection goals are defined:

Information vs. data • Confidentiality: No one should be able to access the information represented by data
Data consists of symbols, without authorization. On a theoretical level, information flow models can be used to
such as “42”, and are a
syntactic concept. Infor- define permissible and prohibited information channels. If unauthorized access to the
mation is represented by underlying data is difficult to prevent, encryption can be used to prevent unauthorized
data and adds meaning to persons from extracting the information contained within the data.
these data. For example,
“42” might represent the • (Data) integrity: Persons not authorized to do so should not be able to change protected
number of employees of a data unnoticed. This may e.g. involve files for which access or write permissions is
company or the current
defined, or sensitive data in the context of e-commerce (such as an online bank trans-
temperature.
fer).
• Availability: No one should be able to prevent authorized subjects from acting within
the scope of their authorizations. This goal may be restricted by other authorized sub-
jects (for example, in the case of shared CPU time), but no restrictions caused by unau-
thorized subjects or by accidental effects should be possible.

In addition to these main protection goals which are often described as the CIA triad, there
are further common goals, for example:

• Authenticity: This refers to the authenticity of the identity of a system or user, which
needs to be proven or verified. Authenticity applies to users who need to prove their
identity in order to access a system such as a webserver.
• Non-deniability (also called non-repudiation): It should not be possible for someone to
deny having carried out a certain action. This is particularly important in e-commerce,
where it is important to be able to carry out legally binding business transactions.

12
• Anonymity: In selected scenarios, it should be possible that natural persons cannot be
identified within a given set of data. This goal does not make sense in all contexts (for
example, in the case of electronic tax returns), but in other contexts it is very important
in order to implement the principle of data minimization (examples: AIDS counseling on
the Web, expression of opinions in authoritarian states).

Obviously, there are many different ways the above protection goals may be endangered,
depending on the object to be protected (individual computer, network) as well as other
factors.

Note that the above protection goals can also compete or conflict with each other. This is
easy to show in the case of anonymity, which is one of the reasons why this goal leads to
many discussions as well as legal disputes: for example, anonymity (on the Internet and
elsewhere) and the state's interest in law enforcement may conflict with each other. On
the one hand, the states have a strong and legitimate interest to prosecute serious crimes;
on the other hand, the individuals have a strong and legitimate interest to be protected
against being observed in their day-to-day behavior.

1.2 Weaknesses and Threats

There are many different vulnerabilities in IT systems that may be exploited by attackers
to compromise the listed protection goals. The first step in analyzing these vulnerabilities
is to try and estimate the extent of the threats that may be aimed at exploiting the vulner-
ability in question. These threats can have very different relevance. For example, certainly
a lack of anonymity in Internet searches for movie theater programs has a lower weight
than a lack of data integrity in an online money transfer.

In addition, consideration should be given - if possible - to how likely it is that the threat
will be exploited by an attack and cause some damage. With the concept of risk, one tries risk
to describe the relevance of such a damaging event. Obviously, in any individual case it is Risks describe events that
may occur and lead to
very difficult to evaluate such a risk quantitatively. negative consequences. A
risk is characterized by
Attacks the combination of the
likelihood of the event
occurring, and the size of
We will now take a detailed look at the potential attacks and their perpetrators – the the resulting damage.
attackers. In the process, some common terminology used in this context will be intro-
duced.

In general, an attack is defined as an unauthorized access or attempted access to an (IT)

system. A distinction is made between passive and active attacks:

in a passive attack, there is "only" a breach of confidentiality, but no further access or

manipulation of data or systems; active attacks, on the other hand, aim at the integrity or
availability of data by manipulating the data or systems. For example, a passive attack
that aims to intercept data transferred in a network, for example log-in data, is called a
sniffer attack.

13
 Spoofing is the name given to an active "masking attack": an example of a spoofing attack
uses false sender information in an email message; another example is the assumption of
a web server's identity and then answering user queries with false data. In a denial-of-
service (DoS) attack the aim is to create an overload by "bombing" a computer or "flood-
ing" a computer network, leading to disruptions or even to the collapse of the attacked
resource. Such an attack is often performed as a distributed DoS attack, called a DDoS
attack, where a distributed network is used to create such an overload on the attacked
resource.

Quite often, it is not always entirely clear whether there is an attack behind the misbehav-
ior of an IT system, or whether the problem is due to a problem in the design or configura-
tion of the system. This lack of clarity largely results from the fact that today's systems are
typically based on many individual software components, and it is not always possible to
tell whether an exploitable weakness has been deliberately built in or is due to a genuine
error in development or configuration.

As varied as the types of attacks are the motives of potential attackers. In companies and
public authorities, typical attackers first of all include the "internal perpetrators", i.e., the
company’s own employees who cause security problems either through carelessness or
intentionally. In times of open systems and all-round networking, however, several other
types of attackers need to be taken into account:

• Hacker: This refers to a technically skilled attacker who uncovers vulnerabilities in IT

systems and exploits them by means of attacks known as exploits. In general, the hack-
er's aim is simply to draw attention to the vulnerabilities (and possibly to himself), with-
out causing any serious damage.
• Cracker: Unlike a hacker, a cracker tries to gain personal advantage by exploiting a vul-
nerability. However, this distinction is often ignored.
• Script kiddie: this term refers to a less technically skilled attacker, who obtains prefabri-
cated exploits from other attackers and uses them to launch attacks themselves - often
purely for the fun of it but sometimes also for personal gain.
• Industrial or economic spies: Time and again, there are press reports or indications that
that corporate data is being attacked with the aim of spying on competitors or even
copying products.
• Intelligence agencies: as has become clear from the publications of former NSA
employee Edward Snowden, the intelligence services are involved in both industrial and
economic espionage as well as in the mass spying on individuals.
• Criminals: the "classic" criminal activity in this context is email- or browser-based
phishing attacks, in which users are tricked into revealing their login credentials. More
recently, there have been frequent incidents of extortionist malware (ransomware) that
encrypts data on the user's computer so that users can no longer access it. The criminal
then offers to provide the user with the key to decrypt the data once the user has paid a
ransom.

URLs and Phishing Attacks

Phishing attacks are often based on using a different URL than expected. The URL of a web
page has the structure scheme://[subdomain.]domain.tld[:port][/path?query]

14
(where we ignore some further, less often used options). URL (Uniform Resource
Locator)
A URL describes the
The scheme describes the protocol used, i.e. http or https for websites. The host name is address under which a
hierarchically structured and contains the so-called top-level domain tld at the end, often certain resource such as a
web page is available.
"de" for German websites, while commercial companies (especially in the USA) are often
Often also called web
registered under the top-level domain "com". The domain describes the name of the address, even though
domain within the top-level domain and must be registered with the registrar of this top- URLs are also used as
addresses of resources
level domain. Optionally, a subdomain can also be defined within the domain, but this is other than web pages,
managed internally by the operator of the domain and is not registered externally. Within e.g. mail addresses or
a host name, further information can be provided by the operator, in particular the port local files.
address, the path of the individual web page, as well as further information referred to as
query, which usually describes database queries for dynamic web pages. Example: In the
URL

https://www.iu.org/why-iu/our-university/

https describes the scheme used, www the subdomain, iu the domain, and org the top-
level domain. Within this host, why-iu/our-university/ defines the path of the refer-
enced web page. Port and query are not given in this URL.

In order to check whether a given link to a URL, e.g. received by email or found on a web
page, is a legitimate URL of the expected operator, the domain and the top-level domain
are primarily relevant. Some attackers try to deceive recipients of the link by entering a
valid domain and top-level domain as subdomains. For example, the URL https://
www.iu.org.example.com refers to the domain example.com, not, as one might
expect, to iu.org. This can easily be misinterpreted, especially on mobile devices that
may only display the beginning of the URL due to space limitations.

In this context, it should also be noted that the URL displayed in the text and the URL
linked from it do not always have to be the same. For example, the text https://iu.org
(on a web page or in an email) may actually be linked to the URL https://
attack.example.com. Many mail programs and browsers now display a warning in such
cases, which should then be taken seriously.

Computers, Networks and Protocols as Objects of Attacks

Attacks that threaten the general protection goals described above may be rather simple
in that they are technically directed against a single subject or object (such as a com-
puter). Alternatively, they may consist of a complex combination of different individual
actions that together make up the attack. If, for example, an attacker attempts to pene-
trate a corporate network without authorization and, by manipulating the address man-
agement system, to redirect internal data to their own device, this attack can succeed by
exploiting vulnerabilities in several components and services in combination.

Today's computers used by businesses, government agencies and private individuals are
mostly based on Windows, Linux or macOS operating systems. Servers as used for a vari-
ety of purposes are also primarily based Linux or Windows operating systems. Mainframes
and supercomputers will not be considered any further here. Similarly, details of access

15
 control in these different operating system worlds will not be discussed here, apart from
once again pointing out the well-known problem of careless use of passwords to access
computer systems.

As a first step to move away from individual computers and move towards local network-
ing in a LAN (Local Area Network) or WLAN (Wireless Local Area Network), a wide range of
security vulnerabilities and potential threats needs to be addressed. This starts with the
fact that the transmission of data is generally unencrypted unless further precautions are
taken. As a result, an attacker who can listen in on the data transfer will also be able to
access the transmitted information. Another problem arises from the fact that attackers
who gain unauthorized access to such a network may be able to redirect interesting data
to their own devices. However, details of the Ethernet technology underlying most net-
works cannot be discussed in detail here. However, such details can easily be found in the
relevant literature or online.

Finally, we must mention Bluetooth. Originally conceived for wireless communication

between devices over short distances, this technology has meanwhile developed into
being a competitor of WLAN.

Looking at communication over larger distances, we now consider wide-area networks

(WANs) as well as SANs (for: Storage Area Network) and cloud computing. A SAN is used for
connecting hard disk systems to server storage systems, whereby larger distances can be
bridged. Data transfer in such SANs is usually based on Fiber Channel networks. The physi-
cal transmission of the signals is usually carried out at a high bit rate via fiber optic cables.

Another wide field of attack objects and scenarios arises when we move into the world of
the Internet and WWW based on the TCP/IP protocol family. Attacks can be directed at net-
work components such as routers, etc., as well as at computers of users accessing the
Internet. They may try to exploit vulnerabilities in the logical design of communication
protocols or exploit flaws in their implementation.

As a result, cloud technology also is vulnerable. In cloud computing, the following service
models are usually distinguished:

• Software as a Service (SaaS), where application software is provided “in the cloud”, i.e.
it is run on some computer provided by the cloud provider and accessed via an Internet
connection.
• Platform as a Service (PaaS), where some environment or platform is provided for the
customers to run their own applications.
• Infrastructure as a Service (IaaS), finally, where an entire infrastructure such as a virtual
machine or storage space is provided to the customer.

Obviously, cloud computing leads to many technical challenges regarding security, as well
as legal challenges regarding privacy.

More recent phenomena that also use the Internet as a communication medium and lead
to new attack scenarios, are the smart home - i.e., houses extensively networked both
internally and to the outside world - as well as connected cars.

16
It has already been mentioned above and must be pointed out again: objects to be protec-
ted do not only include user devices and network components, but also the communica-
tion protocols and services that are responsible for proper communication and that ena-
ble the various applications in the Internet in the first place. An attack on a service is often
made possible by a protocol vulnerability. One example is the Address Resolution Protocol
(ARP), which converts the internal IP addresses in a TCP/IP-based LAN into the hardware
MAC addresses. A successful attack that changes the mapping and which is not prevented
by the protocol can cause large damage.

As one can see, there is no end in sight to the many security problems around us ...

SUMMARY
A precise characterization of the concept of IT security starts with a com-
pilation of the protection goals for subjects and objects in IT infrastruc-
tures, whose practical implementation is supported by technical proce-
dures and systems.

The main protection goals are confidentiality, data integrity and availa-
bility, sometimes extended by further goals such as authenticity, non-
deniability and anonymity. The goals are not always compatible with
each other, i.e., the realization of a certain goal may hinder the realiza-
tion of some other goal. In such a case, a priority decision is required.

An IT system can have various vulnerabilities that pose threats and can
be exploited by attackers. The motives of attackers are diverse, as are
the forms of possible attacks.

The spectrum of possible targets is also wide. First of all, one needs to
consider individual computers and their operating systems with differ-
ent access control mechanisms. This is followed by the numerous types
of networks - especially today's open structures with the dominating
role of the role of Internet technology offer a variety of further points of
attack. The mechanisms used in the networks - especially the Internet -
play a special role in this context.

17
 UNIT 2
FOUNDATIONS OF CRYPTOLOGY AND ITS
CORE COMPONENTS

STUDY GOALS

On completion of this unit, you will be able to ...

– explain the concept of encryption.

– distinguish between symmetric and asymmetric encryption.
– describe the basic concepts of the symmetric algorithms AES and RC4.
– demonstrate the basic concepts of the asymmetric algorithm RSA.
– illustrate the concept of a cryptographic hash function.
 2. FOUNDATIONS OF CRYPTOLOGY AND ITS
CORE COMPONENTS

Introduction
This lesson introduces the most important cryptographic building blocks, such as encryp-
tion methods and hash functions, which are then used to compose further cryptographic
methods and protocols. Above all, it is important to understand the fundamental differ-
ence between symmetric and asymmetric encryption methods and the practical conse-
quences of this difference. Of particular importance is an understanding of the functional-
ity of digital signatures - this is where asymmetric procedures always come into play.
Some important representatives of cryptographic procedures are presented in more
detail.

2.1 Encryption
The best known and most important cryptographic building blocks are the procedures
used for encryption. In general, the aim is to “encrypt” information or data in such a way,
i.e., transform it into other data in such a way that the intended communication partner
can “decrypt” it and thus make it readable/usable for themselves, but an unauthorized
third party cannot. (Of course, you can also encrypt the data on your own PC hard disk,
but in the following, we will concentrate on the aspect of communication, i.e. sending
messages between a sender and a receiver). At first glance, this can only work if the sender
and the recipient have a shared secret - the key - which can be used to encrypt and
decrypt the data. This approach is called symmetric encryption. As it turns out, however, it
may also be sufficient for only the recipient of the data to have a secret key. In this case,
the encryption is called asymmetric. In both cases, it can be said that an encryption
method consists of an algorithm plus key.

Kerckhoffs's principle

In principle, modern cryptology assumes that the security of an encryption method is

based only on the secrecy of the key in question, not of the algorithm used. This is referred
Auguste Kerckhoff to as Kerckhoffs's principle: A cryptosystem should be secure even if everything is known
(1835-1903) about the system except the key that is used to encrypt a particular message (Buell 2021,
Dutch linguist and cryp-
tographer. Today, he is p. 9). The security is based only on the secrecy of the key. This is not a matter of course - in
mainly known for his military contexts, it is still common practice to keep the methods used secret, or at least to
paper “La Cryptographie try to do so. The scientific cryptology community, however, rejects this. New procedures
militaire” which was pub-
lished in 1883 and in should be discussed publicly and checked for weaknesses by the "best minds".
which he introduced the
principle now known
under his name.

20
Possibilities and limits of encryption

Is there a "perfect" encryption method that cannot be "cracked"? The surprising answer
is: yes, there is - the procedure is just unfortunately not practically feasible. The following
example helps to understand this.

Example

Consider two sequences of bits a = a1a2…an and b = b1b2…bn of equal length n. (If e.g. n =
8, then both sequences describe bytes.) Then we define a ⊕ b as the bit sequence

c = c1c2 . . . cn

which is obtained by bitwise addition or XOR of a and b, i.e. for all i = 1, . . ., n we

have

ci = ai ⊕ bi

It is now important to note the following, since this property is often used in encryption
and decryption: If the bit sequence c is XORed again with b, the result a is returned,
expressed as a formula:

a⊕b ⊕b=a

Now consider the following scenario: A wants to send a message a to B consisting of n

bits. As an example, let us assume that n = 64, i.e. the message consists of 8 bytes. Fur-
thermore, let us assume that A and B have previously agreed on a common secret: a key b
of 64 bits, which consists of a random sequence of zeros and ones. Instead of the actual
message, A now sends the bit sequence c = a ⊕ b as an encrypted message over the com-
munication link. B receives and decrypts c by forming c ⊕ b, which - as was shown above -
is the original message a (see the following figure).

Figure 1: Encryption using XOR

21
 If the following three conditions are satisfied

• the key b is truly random

• b is used only once
• the attacker is only able to listen in on the communication, but not able to modify it

then the attacker has no chance to decrypt the message and read a.

This sounds quite plausible. Given that the three conditions are satisfied, the method pro-
vides perfect security. In the literature, this scenario is usually considered for a continuous
bit stream (i.e., without an upper limit for the length). The two sides must then have a
common key k, which is at least as long as the message, consists of a random bit
sequence, and is used only once: This encryption procedure is called a one-time pad.

This scenario shows that it is possible to imagine absolutely secure encryption systems,
but the problem lies in the implementation: how are A and B supposed to agree confiden-
tially on what is in principle an infinitely long random sequence of bits as a shared secret?
The question also arises why the two do not communicate confidentially from the outset -
without any need for encryption. The situation is illustrated in the following figure.

Figure 2: Agreement on key

Encryption methods that can be implemented in practice always work with keys of a limi-
ted length - such as the AES method with 128 or 256 bits or the RSA method with typically
2048 or even 4096 bits. Since the "plaintext" to be encrypted will usually be longer than
the key used, the procedures must be designed in such a way that the respective key is
applied multiple times or variations of an initial key are applied to parts of the text.

However, it is clear that if the key, on which alone (see Kerkhoffs's principle) security is
based, has only a finite length, then there is also only a finite number of possible keys - an
attacker with sufficient resources can thus theoretically find out the key by trying out all
possibilities! Consequently, to be secure, the procedures must be designed such that, with
sufficiently long keys, a brute force attack becomes practically impossible.

22
Block and stream ciphers

The RSA method mentioned above is a block cipher. This means that the data to be
encrypted is divided into blocks of a fixed length and these blocks are then encrypted indi-
vidually by repeatedly applying the same function. The AES algorithm, which is still to be
considered, is also a block cipher.

If (as is usually the case) the length of the plaintext is not divisible by the block length,
breaking the plaintext into blocks leads to an incomplete last block. This is usually
resolved by “padding”, i.e. by adding bits according to defined rules to complete this last
block.

In stream encryption, a plaintext bit sequence of any length, similar to the one-time pad, is
linked bit by bit by an XOR operation with a key. This key is a bit sequence which, starting
from a secretly agreed initial value, produces "pseudorandom bits" according to a fixed
algorithm. Here again the algorithm may be known by an attacker, since the secret is in
the initial value. An example of such a method, the algorithm RC4, is briefly presented
below. As an alternative to bit-by-bit encryption with XOR, stream encryption with a differ-
ent algorithm can also encrypt an entire character (usually byte) at a time.

Cryptography, Cryptanalysis and Cryptology

The standard terminology is as follows: the study of encryption procedures is called cryp-
tography. If one takes the viewpoint of an attacker who initially does not have the relevant
key, but nevertheless attempts to obtain either the key or the plaintext directly by analyz-
ing the encrypted data, this is referred to as cryptanalysis. Cryptography and cryptanalysis
are finally combined in the generic term cryptology.

In the following explanations of individual cryptographic procedures, the cryptanalytical

aspect - i.e., how secure the procedures are against attempted attacks - is always taken
into account, without this always being mentioned separately.

2.2 Symmetrical Encryption

The "classic" among the symmetric encryption methods is the Caesar cipher or Caesar
chiffre, which is presented first. This is followed by a description of two important sym-
metric encryption algorithms that are used in numerous technical systems today. These
are respectively a block cipher and a stream cipher algorithm.

Caesar cipher

This encryption method is named after the Roman emperor and general G. J. Caesar, who
is said to have used it in his communications with his generals. In it, a natural number n
between 1 and 25 is used as the key. The plaintext is encrypted by replacing each letter

23
 with the letter that occurs n positions later in the alphabet. As an example, this means that
with the key "3" (i.e.: shifting three letters to the right), the text "a student" becomes "d
vwxghqw", because a is encrypted as d, s as v, and so on.

Of course, with today's knowledge and available tools, this procedure is no longer ade-
quate. Someone who has access to an encrypted text and knows that the Caesar method
has been applied to an English text only needs to find out the most frequently occurring
letter in the encrypted text and can conclude (if the text is long enough) that this letter
must correspond to the "e" in the original text - thus he has found out the number of shift
positions (i.e. the key). This is because in English texts the "e" is the most frequently occur-
ring letter. One knows even more: In most sufficiently long English texts the letters occur
with respect to their frequency in the following order (Math Explorer’s Club, 2004):

ETAOINSRHDLUCMFYWGPBVKXQJZ

The Caesar cipher is a special case of a so-called monoalphabetic cipher, where each letter
is replaced by the same (usually different) letter wherever it occurs. However, even an
arbitrary substitution rule that is not based on a simple shift (as in the Caesar method) is
easy to "crack" by today's standards, because if the ciphertext is not too short, the fre-
quencies of the occurring letters lead directly to the decryption rule (the most frequent
letter corresponds to the "e" in the original text, the second most frequent to the "t", etc.).

There have been numerous generalizations and improvements of the monoalphabetic

methods. With the Vigenère cipher one agrees upon several different shifts, which are peri-
odically applied one after the other again and again. This as well as other methods are
summarized under the term polyalphabetic substitution, which include the method
Enigma implemented by the Enigma. This is a cipher machine which was used by the German
is a cipher machine which Wehrmacht during the Second World War. The letter shifting used in each case results
was used by the German
Wehrmacht during the from a complex interaction of several "rotor discs" in a "rotor machine", which leads to a
Second World War. Break- very long period and was therefore quite difficult to crack. An English group of scientists
ing this highly secure around the computer science pioneer Alan Turing managed to do this - this was later the
code influenced the out-
come of the war by allow- subject of several movies.
ing convoys across the
Atlantic to evade the Ger-
All these procedures and their refinements are no longer good enough for today's condi-
man submarines.
tions. Today, only procedures are used for which unauthorized "cracking" would demon-
strably require immense computing power that is not available to anyone in the world.
Since the performance of computers - and thus also that of potential attackers - is con-
stantly increasing, the procedures have to be checked again and again, and possibly secret
keys have to be extended or completely new procedures have to be used.

At this point, we would like to point out the freeware CrypTool, which can be downloaded
from the Internet. Here you will be introduced to the most common symmetric and asym-
metric encryption methods as well as cryptanalysis techniques by means of demonstra-
tions, and you can also easily try all this out yourself.

24
Advanced Encryption Standard (AES)

The Rijndael algorithm, designed by two Belgian scientists, was declared the Advanced
Encryption Standard (AES) in the USA in 2000 and thus the successor to the Data Encryp-
tion Standard (DES). The DES algorithm had previously been used worldwide for many
years in various applications, but is no longer recommended today because of its compa-
ratively low key length (64 bits). The 3DES modification, which works with two or three
DES keys and a combination of encryption and decryption, is still frequently used. Another
AES predecessor is the International Data Encryption Algorithm (IDEA), which works with a
key length of 128 bits and is still included as an option in some security protocols.

The AES algorithm is a method for block encryption that works with a key length of 128,
192 or 256 bits, where the blocks to be encrypted consist of 128 bits. (The original Rijndael
algorithm also allowed different block sizes but these were not included in the AES stand-
ard). The following is a rough outline of how AES works for the key size of 128 bits. A block
to be encrypted thus consists of 16 bytes. These 16 bytes are numbered
b0, b1, . . . , b15 and arranged in the form of a 4 x 4 matrix B as follows:

b0 b4 b8 b12
b1 b5 b9 b13
B=
b2 b6 b10 b14
b3 b7 b11 b15

The matrix B is now modified again and again in several "rounds", the resulting encrypted
block at the end also consists of 16 bytes. The number of rounds depends on the key
length. In each of the rounds, parts of the 128-bit key are used - how these partial keys are
formed from the key is of central importance for the entire algorithm. Of course, all modifi-
cations made to the block during the rounds are reversible, because the result should be
decryptable again! The general structure of the AES algorithm is shown in the figure
below. In the case considered here (128 bits for block and key), r = 10, i.e., after the initial
round, nine standard rounds and one final round take place.

25
 Figure 3: Structure of the AES algorithm

As can be seen in the figure, the rounds are constructed from four different basic transfor-
mations, with only three of these transformations applied in the final round:

• ByteSub
• ShiftRow
• MixColumn
• AddRoundKey

The functionality of these transformations is not explained in detail here, rather some
hints shall suffice:

In ByteSub, each of the 16 bytes is replaced by another according to a fixed procedure. The
replacement rule follows an algebraic operation (inverse formation and affine linear trans-
formation) if one understands the bytes as elements of a certain algebraic structure with
256 elements. This makes the substitution easy to implement.

26
(The algebraic structure used here is a so-called field - this is the name given in mathemat-
ics to a number range in which, as with the real numbers, addition, subtraction, multipli-
cation and division can be performed using the usual calculation rules. For every power pn
of a prime p there is a field with pn elements).

With the transformation ShiftRow the rows of the current matrix B are cyclically "shifted"
by different numbers of places to the left.

With MixColumn each column of the current matrix is replaced by another column. The
replacement rule again follows a complex algebraic operation, which is of course chosen
in such a way that this step is also reversible.

In the transformation AddRoundKey, the current matrix (or the current 128-bit vector) is
XORed bit by bit with a 128-bit round key derived from the original key. It should be clear
that the rule for generating the eleven required round keys from the originally given key is
of particular importance. The procedure is based on XOR operations, cyclic shifts and the
replacement rule already used with ByteSub.

As is clear from the description, the AES algorithm is based on complex algebraic opera-
tions and simple cyclic rotations. The AES is immune to all attacks on symmetric encryp-
tion methods known so far. Another decisive factor for the selection was that the algo-
rithm is easy to implement in hardware and software and requires little memory - the
latter is particularly relevant for applications on smart cards.

Operating modes in block encryption

With block encryption, the question arises as to how exactly the encryption takes place if
(to stay with the AES example) a longer plaintext is to be encrypted with a 128-bit block
length. There are different ways how to encrypt the individual blocks in a sequence of
blocks, defined by different “block cipher modes”. The simplest method is to encrypt one
128-bit block of plaintext at a time with this key - this is known as Electronic Code Book
mode (ECB mode). If a block of plaintext occurs twice, this leads to the same encryption -
an attacker could take advantage of this. In Cipher Block Chaining Mode (CBC mode), an
encrypted block is XORed with the next block to be encrypted before this result is then
encrypted. This is an enormous complication for an unauthorized attacker, but a single bit
error in one block affects all blocks that follow.

Apart from the electronic codebook mode ECB described above, all other modes use addi-
tional information such as the previous block or a counter in order to ensure that the
same plaintext block leads to a different ciphertext even when encrypted using the same
key. The resulting block cipher modes differ considerably in their properties, including
their security, the effects of individual bit errors or lost blocks on other blocks, and
whether encryption and/or decryption can be sped up by working on different blocks in
parallel.

27
 RC4

The algorithm RC4 was developed in 1987 by Ronald L. Rivest, who was also one of the
authors of the famous RSA chiffre introduced below. RC4 was for a long time the most
widely used algorithm in software products for stream encryption. It is used in the web
security technology SSL/TLS as well as in the encryption performed under the name WEP
in WIFI. In recent years, however, RC4 has come under criticism for various weaknesses,
and in 2015 its use in TLS was finally banned for the future by the IETF (Internet Engineer-
ing Task Force).

Several algorithms, in particular Rabbit, Snow 3G and Spritz are under discussion as suc-
cessors of RC4, to provide a fast stream encryption method for various technical applica-
tions. Nevertheless, RC4's operation will be briefly outlined here because of its impor-
tance. RC4 is not based on linear feedback shift registers (LFSR), as is the case for many
stream ciphers, but on simple addition and interchange operations at the byte level. This
has the advantage that software implementations of RC4 can also work very fast, while
methods based on LFSRs allow very fast hardware implementations but only relatively
slow implementations in software.

RC4 allows key lengths from 5 to 256 bytes. The basic principle is that a sequence of pseu-
dorandom bit blocks of length n is produced, which can then be superimposed on plain-
text blocks for encryption using an XOR operation. In applications, n = 8 is commonly
used (i.e., one byte produced at a time), so only this case is outlined below. The core of the
algorithm is that all 256 possible bytes (i.e. the binary numbers equivalent to the decimal
numbers from 0 to 255) are held in memory cells S0, S1, . . . , S255. According to a
prescribed procedure, the contents of these memory cells are swapped and eventually,
the contents of one memory cell is selected as the byte to be output. The algorithm con-
sists of two parts: first, the Key Scheduling Algorithm (KSA), which uses the secret key for
an initial swap of the memory contents, and second the Pseudo Random Generation Algo-
rithm (PRGA), which then performs the further swaps and the output of the respective
byte.

The two algorithms are now described in pseudo code. As can be seen, the main principle
is to "mix up" the initial contents of the memories S0, S1, . . . , S255 in a key-control-
led manner and then to perform further swaps in a continuous loop - in each case depend-
ing on the current memory contents - and to output a byte for the current encryption.

KSA

load the numbers 0, 1, 2, …, 255 into memories S[0], S[1], …, S[255};

load the key bytes into memories K[0], K[1], …, K[255]
j := 0;
for i = 0 to 255 :
j := (j + S[i] + K[i]) mod 256
swap S[i] and S[j];

28
If the key is shorter than 255, the instruction "load the key bytes into memories K[0],
K[1], ... , K[255]" de scribe s that the ke y byte s are re pe ate dly loade d into K[i] until all
memories are filled.

PRGA

i := 0;
j := 0;
FOR n=1 to length of plaintext: i := (i + 1) mod 256
j := (j + S[i]) mod 256
swap S[i] and S[j]
t := (S[i] + S[j]) mod 256
K := S[t];

The output of each iteration of the loop is a byte K. Note that so far, the computation is
independent of the plaintext to be encrypted, apart from the number of loop iterations
performed. For the encryption - as is usual for stream encryption - the output K is XORed
with the next byte of the data to be encrypted.

As mentioned above, a number of weaknesses in RC4 has been uncovered in recent years.
In practice, these are mainly implementation weaknesses; for example, when KSA is used
as part of the WIFI security algorithm WEP, other data which is openly known or easily pre-
dictable is loaded into the K[i] memories during initialization in addition to a short secret
key, making the overall system insecure.

2.3 Asymmetric Encryption

The basic principle of asymmetric encryption can certainly be described as "revolution-
ary": communication partners do not have to agree on a shared secret. The best-known
asymmetric encryption method is the RSA method named after the scientists Rivest, Sha-
mir and Adleman, which is described below. Elliptic curve cryptography (ECC) is then dis-
cussed - corresponding asymmetric methods have become firmly established in practical
use in recent years.

Asymmetric Procedures

One generally speaks of asymmetric encryption if two keys - one public and one private -
are assigned to each participant, which can be used for different functions such as encryp-
tion or digital signatures. Note the terminology: not every asymmetric procedure is an
asymmetric encryption procedure - the example of the Digital Signature Algorithm (DSA) is
discussed elsewhere.

In asymmetric encryption, the data at hand is encrypted using the public key of the
addressee, who alone can transform it back using their private key (which matches the
public key). The addressee of the data is typically a communication partner to whom the

29
 data is to be transmitted confidentially. However, you can also be the addressee yourself if
you want to encrypt the data on your own computer system and thus protect it from unau-
thorized access - in which case you must use your own public key.

The RSA Algorithm

The operation of the RSA procedure is based on the fact that exponentiation modulo n is a
trapdoor function trapdoor function for large natural numbers n. To understand the RSA procedure, we first
A one-way function f is a introduce Euler's phi function Φ: Given a natural number n, Φ n returns the number of
function that is easy to
compute but hard to natural numbers i that are less than n and relatively prime to n, that is:
invert, i.e. it is unfeasible
to compute a value x
Φn = i ┤ 1 ≤ i < n, gcd i, n = 1
given f(x). A trapdoor
function is a special case
of one-way function that As usual, gcd is the abbreviation for the “greatest common denominator”.
is easy to invert given
some secret information.
As an example, Φ 12 = 1,5, 7,11 = 4. For any prime number n, Φ n = n − 1.

For the RSA procedure to work the following theorem of Euler, which he proved more than
200 years ago, is crucial:

For any two mutually prime natural numbers a and n, the following equation holds

a Φn = 1 mod n

The basic idea of RSA is to choose two natural numbers e and d for which e · d − 1 is a
multiple k · Φ n of Φ n . In that case, for all values of a which are mutually prime to n:

ae · d = ak · Φ n +1 = aΦ n k·a = a mod n

In these cases you can now encrypt a as c = ae mod n , and cd mod n will return the ini-
tial value a. The crucial point now is: if n is very large (e.g., a decimal number of at least
200 digits), then one cannot easily calculate Φ n or d even if one knows n and e: exponen-
tiating with e represents a trapdoor function, where the secret of the trapdoor function
(the trapdoor) is the number d.

How is this implemented in the RSA process? After all, the legitimate creator of the asym-
metric key pair must be able to determine the matching d for n and e! The trick lies in the
initial choice of n. It works as follows:

A user of RSA who wants to receive encrypted messages first chooses two different prime
numbers p and q and calculates n = p · q. (At least orders of magnitude of 2048-bit num-
bers are now recommended for secure use.) One can easily reason that in such a constella-
tion Φ n = p − 1 q − 1 . Note, however, that someone who knows only n, but not the
factorization in p and q, cannot easily compute Φ n ! Afterwards, the user chooses as their
public key a number e which is mutually prime to Φ n . Additionally, a private key d with
the property e · d ≡ 1 mod Φ n is selected. This is easy with the knowledge of Φ n –
just use the well-known Euclidean algorithm. The user can now publicly announce the

30
numbers n and e (their public key), and anyone can send them a message m encrypted in
the form of c = me mod n , which only they can decrypt again using
cd = med = m mod n .

A note: the reader may have noticed that according to the above argumentation with Eul-
er's theorem the encryption and decryption as described only work if a and n are mutually
prime. However, it can be shown that under the special conditions concerning n and e
here, the procedure also works if this is not the case, but we will skip the proof here.

Since the factorization of n into p and q is not published and there is no fast (publicly
known) algorithm for the factorization of natural numbers to date, an attacker cannot
easily compute Φ n and d, even though they know n and e.

In this description we assumed that the message m to be encrypted is a natural number -

and additionally that m < n, since otherwise during decryption we would compute a
number congruent to m modulo n rather than m itself. However, all these restrictions do
not pose a problem, because the data to be encrypted can always be divided into appro-
priately sized blocks and interpreted as natural numbers (e.g., via the decimal value of
ASCII characters).

Example

We start with the two prime numbers p = 47 and q = 71. Then n = p · q = 3337. (Of
course, these numbers are far too small for any practical application). The number e must
now be chosen as a number that is mutually prime to p − 1 · q − 1 = 46 · 70 = 3220.
As an example, we choose the prime number 79. Now d is to be chosen with the property
e · d = 1 mod 3220 . Here, Euclid's algorithm yields d = 1019.

Now that all numbers are fixed, the user can publish the public key consisting of e and n,
keeping their private key d to themselves. (The information about p and q should be
destroyed as a precaution).

Suppose now someone else wants to send the message m = 6882326879666683 to the
user in encrypted form. M must first be divided into smaller blocks, because only num-
bers below n = 3337 are to be encrypted. A division into six blocks yields:

m1 = 688 m2 = 232 m3 = 687 m4 = 966 m5 = 668 m6 = 3

Encrypting the first block yields

c1 = 68879 mod 3337 = 1570

Encryption of the remaining blocks is left as an exercise to the reader.

31
 Also verify that encryption works as intended: 15701019 mod 3337 = 688. (Obviously,
there are algorithms for exponentiation modulo a number that are much faster and need
less memory than first computing 15701019 and then dividing by 3337 to calculate the
remainder.)

If the RSA method is to be used in a communication network, each participant must be

assigned a public and a private key. There are plenty of such keys, but it is clear that not
everyone has the possibility or the desire to generate their own keys. This is where the so-
called trust centers come into play, which support key management - i.e., key generation,
distribution and administration.

A special property of the RSA method is that c′ = md mod n can also be formed first (i.e.,
the "decryption" of a block that was not encrypted at all) and then c′e also yields m again -
this property can be used for digital signatures.

The version of RSA described above, often referred to as "textbook RSA," contains the cen-
tral idea of the algorithm, but it is still very insecure. Partly, this is because the same plain-
text always leads to the same ciphertext, which allows a number of attacks. Even the
knowledge that a certain part of a message is sent repeatedly can provide important infor-
mation to an attacker, even if they cannot decrypt the message. So, similar to the different
block modes in symmetric encryption, one needs an approach in asymmetric encryption
so that the repetition of a message cannot be detected as such by an attacker. For this
purpose, a form of "padding" of the message is usually used, i.e., random characters are
added to the message before encryption according to defined rules. These random char-
acters can then be deleted again after decryption.

Elliptic Curves

Another group of cryptosystems commonly used today is based on the mathematical con-
cept of elliptic curves and is therefore referred to as elliptic curve cryptography (abbrevi-
ated: ECC). Just like RSA, these are asymmetric cryptosystems, but they have the signifi-
cant advantage of being much more efficient than RSA and similar systems.

An elliptic curve over ℝ is obtained as the set of all points in the x-y plane that satisfy an
equation of the form

y2 = x3 + ax + b

2
(For technical reasons, 4a3 + 27b ≠ 0 is additionally required.) The following figure
shows the elliptic curve y2 = x3 − 7x + 9 as an example.

32
Figure 4: An elliptic curve in the plane of real numbers

Obviously, this curve does not represent a function, because there are usually two possi-
ble y-values for one x-value - hence the designation "curve" and not "function diagram".
The curve is symmetrical on the x-axis.

More generally, elliptic curves can also be defined over finite fields rather than over real
numbers, but this will not be discussed further here.

The following mathematical properties of elliptic curves are central for their use in asym-
metric encryption:

Given any two points of an elliptic curve, an operation can be introduced which defines a
third point which also lies on the curve. This operation is associative and commutative,
i.e., given a larger number of points, one can connect two at a time in any order to form a
third point without the order having any effect on the result. This operation is called addi-
tion of points of the elliptic curve and is represented with the usual addition sign +. (Some
representations also call this operation multiplication and the scalar multiplication descri-
bed below exponentiation).

It is easy to form the k-fold addition Q = k · P = P + … + P (k times), i.e. scalar multipli-

cation, for a given point P of the curve, but conversely it is very difficult to determine k for
a given P and Q = k · P . The reason for this is that with the help of binary representation
of k, the calculation of Q = k · P only requires about 2 · log2 k additions instead k − 1 of
additions. A simple example: for k = 13, the binary representation is
k = 8 + 4 + 1 = 1 · 23 + 1 · 22 + 0 · 21 + 1 · 20. Now to calculate k · P , we calculate:

33
 1. 2P = P + P
2 . 4P = 2P + 2P
3 . 8P = 4P + 4P
4 . 12P = 8P + 4P
5 . 13P = 12P + P

So instead of 12 addition steps, only 5 steps were needed, and for the much larger values
of k used in cryptography, the difference also becomes much larger.

How public and private keys can be generated on this basis shall not be shown here in
detail.

It is interesting to note that with elliptic curves, the difficulty of inferring the correspond-
ing private key from the public key is not due to the factorization problem (which has not
been satisfactorily solved algorithmically), but to the problem of calculating discrete loga-
rithms:

Given a natural number a as a base and another natural number n. The discrete logarithm
problem denotes the task of calculating the discrete logarithm x of a given number y

x = loga y mod n

i.e. of finding x such that y = ax mod n .

To date, there is no known efficient solution to this problem either.

Based on the described addition of points on an elliptic curve, some widely used asym-
metric cryptographic algorithms can now be transferred to obtain, for example, Elliptic
Curve Diffie-Hellman (ECDH) as used for the agreement of keys, Elliptic Curve Integrated
Encryption Scheme (ECIES) as used for encryption, and Elliptic Curve Digital Signature
Algorithm (ECDSA) as used for signing messages.

These algorithms based on elliptic curves are of particular interest for technical applica-
tions because they require significantly shorter key lengths than RSA and similar asym-
metric methods: While keys of 2048 or even 4096 bits are recommended for the RSA
method today, comparable security can already be achieved using keys of length 224 or
256 bits for elliptic curves. For this reason, ECC is often used in resource-constrained tech-
nical environments such as smartcards.

It is important to realize, however, that the security of ECC cryptosystems depends heavily
on the parameters used, particularly on the elliptic curve used. Definitions of ECC crypto-
systems, therefore, fix the parameters and thus the elliptic curves to be used. BitCoin, for
example, uses the curve y2 = x3 + 7, designated as Secp256k1, but not over the real num-
bers as described here, but over a particular finite field.

34
2.4 One-way Functions and
Cryptographic Hash Functions
One-way functions

As seen above, the operation of asymmetric methods is based on the fact that a private
key cannot (so far) be computed efficiently even if the corresponding public key is availa-
ble. The general mathematical concept behind this is that of one-way functions:

Let X and Y be sets of numbers. A one-way function f : X Y is a function that, for any
value x ∈ X, is easy to compute, but there is no efficient way to compute a preimage x
with f x = y for any given y ∈ Y , if such a preimage x exists.

Note that this is not (as usual) a strict mathematical definition - what does "easy to com-
pute" mean? And if there is no efficient method today, one could be found tomorrow ...

Example:

The mapping f : ℕ × ℕ ℕ, m, n m · n which, given any pair of natural numbers,

computes the product of these numbers is a simple one-way function. As mentioned
before, the discovery of an efficient method to invert this mapping would render the RSA
method useless.

A significant threat to this one-way function arises from quantum computers, which are
currently still in an early stage of development. However, with the so-called Shor algo-
rithm, an algorithm for quantum computers is already known with which prime factoriza-
tion is possible very efficiently, as is the calculation of the discrete logarithm. As soon as
quantum computers are also able to compute with large numbers, most of the one-way
functions currently used in cryptography, for example in RSA, are no longer secure.

For this reason, a lot of effort is currently put into research on so-called post-quantum
cryptography, in which new algorithms are being developed that, according to the current
state of research, cannot be computed efficiently even with quantum computers.

In practice, one-way functions are used in many different applications such as the storage
of passwords. In asymmetric encryption, encryption with a public key can also be regar-
ded as a one-way function, because it is not possible to determine the original plaintext
efficiently. However, there is a special feature: the owner of the corresponding private key
should be able to recover the plaintext. Such a constellation is referred to as a one-way
function with trapdoor, or “trapdoor function” for short: The private key is the secret (the
trapdoor) that can be used to cancel the one-way property.

35
 Cryptographic Hash Functions

Hash functions are widely used in many areas of computer science – for example, in data-
base search and access or as checksums to ensure data integrity. In general, hash func-
tions are functions that assign bit sequences of a limited or even fixed length to arbitrarily
large data sets. Since the function can be applied to an unlimited number of data sets, but
there is only a finite number of possible function values, a hash function ℎ can of course
not be injective. A case where ℎ s1 = ℎ s2 for different values s1 and s2 is called a colli-
sion.

In cryptography, hash functions must satisfy additional requirements to be cryptographi-

cally secure (or cryptographic for short). Such cryptographic hash functions are for exam-
ple used for digital signatures. A cryptographic hash function maps an arbitrarily large
amount of data (more precisely: an arbitrarily long bit sequence D) to a bit sequence of
uniform length m called the hash value ℎ D . (Typically, m = 128, m = 160, or m = 256.
Larger values are also possible.) The following requirements must be met by a crypto-
graphic hash function ℎ:

• Given D, it is easy to compute ℎ D .

• Given y, it is very difficult or practically impossible to compute D such that ℎ D = y.
• Given D, it is very difficult or practically impossible to find a D’ different from D such
that ℎ D = ℎ D’ .

The first two requirements state that h is a one-way function. The third requirement is
called “weak collision resistance”; it is for example used in digital signatures where one
only signs the hash value of a document rather than the document itself. If it was possible
to find a different document with the same hash value, it would no longer be clear which
of the two documents has been signed.

Sometimes we need the following stronger requirements called collision resistance:

• It is very difficult or practically impossible to find values D and D’ such that

ℎ D = ℎ D’ .

It is much easier to find arbitrary values D and D’ with the same hash value, rather than
find a value D’ with the given hash value ℎ D’ = ℎ D . Therefore, the requirement that
this is still very difficult is a stronger requirement than weak collision resistance.

To achieve (weak) collision resistance, it is important that a small change in the input
value D leads to a large change in the resultℎ D (avalanche effect). In this way, similari-
ties of different input values are no longer detectable in the hash values. Ideally, therefore,
any change in one bit of D will result in half of all bits of ℎ D being changed.

Structure of Cryptographic Hash Functions

Most cryptographic hash functions split the message m into a sequence of blocks
m1, m2, . . . , mn, where the last block is padded to become mn* with the correct
block length. As shown in the figure, the hash value of m is computed iteratively by pro-

36
cessing each block together with the result of the previous block by applying a compres-
sion function Comp. The result of processing the last block is the hash value of the entire
message.

Figure 5: Typical Structure of Cryptographic Hash Functions

Secure Hash Algorithm (SHA)

The SHA algorithm and its descendants are the most widely used cryptographic hash func-
tion. In the following, the functionality of SHA-1, which was introduced in 1993 and differs
from the original SHA only in a small detail, is briefly outlined.

SHA-1 follows the iterative structure described above, using blocks of 512 bits length and
creating hash values of 160 bits length. The compression function consists of 80 steps per
block, where each step consists of applying a combination of primitives such as XOR and
bitwise shifting by various distances to subblocks of 32 bits.

After attacks on SHA-1 became known in the years 2004 to 2006, the US-American NIST
(National Institute of Standards) recommended the use of procedures from the SHA-2
family, which use longer blocks and allow longer outputs (between 224 and 512 bits). In
October 2012, the Keccak method was finally declared the SHA-3 standard to replace
SHA-2. Today, both SHA-2 and SHA-3 are widely used.

MD5

The MD5 method ("Message Digest") works similarly to SHA, but it only provides a 128-bit
hash value. The precursor, MD4, was introduced by R. Rivest in 1990 (Paar, C. & Pelzl, J.,
2010, p. 304).

In the late 1990s, there were some results that cast doubt on at least the compression
function used in the MD5 procedure, so that subsequently MD5 was no longer recommen-
ded for a cryptographic hash function and today generally is considered broken. Never-
theless, the method is still widely used today because it is used in numerous technical
applications - for example, in OpenSSL.

37
 SUMMARY
The term cryptography was originally understood to mean the science of
encryption. As we understand it today, it encompasses all mathematical
processes and algorithms used for IT security purposes - in addition to
encryption, for example, the authentication of persons or data. Crypt-
analysis refers to the scientific methods used to "break" such proce-
dures, and cryptology ultimately covers both terms.

In encryption, a distinction is made between symmetric and asymmetric

procedures. In contrast to symmetric encryption which uses the same
key for encryption and decryption, asymmetric encryption uses different
keys for decryption and for encryption; this has great advantages for
managing and exchanging keys.

In symmetric encryption, a further distinction is made between block

and stream ciphers. Important representatives of the two variants are
the block encryption method Advanced Encryption Standard (AES) and
the stream encryption method RC4.

The "classic" (because historically the first) representative of asymmet-

ric encryption methods is the RSA method. Newer asymmetric methods,
which are mathematically based on elliptical curves, achieve the same
degree of security using shorter key lengths, and are therefore increas-
ingly used in technical systems.

One-way functions and cryptographic hash functions are presented as

further basic cryptographic building blocks. While a one-way function
only requires that the inverse is very difficult to compute, a crypto-
graphic hash function should additionally be collision resistant - i.e., it is
required that it is also not efficiently possible to find two original images
with the same function value.

38
 UNIT 3
BASIC CRYPTOGRAPHIC APPLICATIONS

STUDY GOALS

On completion of this unit, you will be able to ...

– discuss the most important procedures for the exchange of cryptographic keys.
– describe the additional measures necessary to use asymmetric encryption for digital
signatures.
– explain the main algorithms used for securing the authenticity of data.
– demonstrate the relationship between steganography and cryptography.
 3. BASIC CRYPTOGRAPHIC APPLICATIONS

Introduction
Based on the cryptographic building blocks such as symmetric and asymmetric encryp-
tion methods and hash functions, various types of basic applications and protocols can be
compiled, which in turn can be converted and implemented in concrete technical proto-
cols. The multilevel nature given here can be well illustrated by the example of the digital
signature:

• First, you have an asymmetric method, which is suitable for digital signature purposes.
• Next, a flow of computation steps (protocol) is established, within which a private key is
used to implement the functionality of a signature.
• In order to be able to use this in a real environment, an implementation must be cre-
ated and this must be integrated into an appropriate technical environment - this
means here in particular: technical realization of the processes for signing and verifying
a signature, key generation, secure storage of private keys, publication of public keys,
etc.

In addition to key exchange and digital signatures, this lesson also addresses the topic of
digital identity, which has recently taken on special significance. It is about proving the
identity of persons and objects in the digitalized reality - especially the "online world" - in
a clear and verifiable way.

The topic of steganography is somewhat off the beaten track, insofar as it cannot be coun-
ted as part of cryptology or its applications: steganography is not about encrypting, but
about "hiding" information. Nevertheless, there are numerous areas of contact and over-
lap with cryptography.

3.1 Key exchange and Hybrid Processes

In all applications of cryptographic methods - whether for encryption or for any other pur-
pose - it is absolutely important that the keys used are handled properly and securely: if
secret keys fall into the wrong hands, all effort put into cryptography is wasted.

There are several aspects that need to be addressed with regard to cryptographic keys:
their secure generation, secure exchange (between two communication partners) or
secure distribution (in the case of several actors), storage, certification and archiving, and
finally blocking or destruction. Together, these tasks are referred to as key management.

Pseudo-random generators are used for the technical generation of symmetric keys (i.e.,
keys that are to be used in a symmetric encryption procedure). Such a generator is an
algorithm that, when applied multiple times, produces a sequence of numbers or symbols

40
that "looks" random. The output of the algorithm is, of course, not random - the decisive
factor is that the generation rule appears so complex and thus opaque that the next value
in each case is practically unpredictable.

When generating asymmetric keys, the problems are somewhat different: here, the main
challenge is to generate key pairs consisting of a public and a private key that match each
other, but it must be practically impossible to calculate the private key from the public
key.

In the further course of this learning cycle, the focus is on key exchange - more precisely,
the exchange of symmetric keys. The scenario consists of two parties A and B, often called
Alice and Bob in cryptography, who want to use an insecure communication channel to
agree on a secret symmetric key to be used for further communication. It is obvious that
this is quite a challenging task: Alice and Bob want to agree on a secret without unauthor-
ized eavesdroppers, and they want to use this secret to communicate confidentially after-
wards - it is the "first step", so to speak, because they do not yet have a shared secret. In
principle, there are two ways to solve this problem:

1. Alice and Bob make use of a trusted third party who "knows" both of them and helps
them with the initial exchange.
2. Alice and Bob use an asymmetric method to exchange the symmetric key securely.

In the following, we will present one example each of these two approaches.

The Needham–Schroeder protocol

With this protocol, both mutual authentication and the secure exchange of a secret key
take place. The basic assumption is that a trusted authentication and key distribution
server AS is available. Each participant X - i.e., Alice and Bob - possesses a secret key Kx
that it has agreed upon with the server AS and that no one else knows.

The communication flow is initiated by Alice who transmits to AS the user IDs of Alice and
Bob as well as a randomly chosen number ZA:

1A AS: A, B, ZA

AS then generates a session key KA, B which is securely transmitted to both Alice and Bob
and can then be used for encryption between them.

The next steps are now noted in short form below; to simplify the notation, the encryption
of a message M with the key K is represented as K M . (The symmetric encryption algo-
rithm used is not specified here and must of course be known to all actors in the case of
application).

The steps involved are:

41
 2 AS A : KA ZA, B, KA, B, KB KA, B, A

3 A B : KB KA, B, A
4 B A : KA, B ZB
5 A B : KA, B f ZB

As can be seen, in step 3 Alice only passes KB KA, B, A on to Bob, without being able to
decrypt it. However, Bob can decrypt this and both are then in possession of the key
KA, B. Mutual authentication takes place implicitly here, since no one else is in possession
of the correct keys to complete the process. Steps 4 and 5 are used to ensure for Bob that
the message received in step 3 was not a replay of an old message. Note that the function
f used in step 5 may be common knowledge.

For completeness, it should be mentioned that a variant of this protocol with asymmetric
encryption also exists.

Diffie–Hellman Key Exchange Protocol

The special significance of the Diffie-Hellman method, which was introduced in 1976
(Paar, C. & Pelzl, J., 2010, p. 206), lies in the fact that it was the first published asymmetric
method. It is still used today in several variants, including the widely used Internet secur-
ity protocol SSL/TLS. The protocol is used to securely agree on a key between two commu-
nication partners A and B, who then want to communicate confidentially using this key
and a symmetric procedure.

A special feature of the Diffie-Hellman method is that, although it is an asymmetric

method in the sense that it is based on an interplay between publicly known information
and information concealed by the participants, it is not an asymmetric encryption method
with matching pairs of public and private keys. Instead, it is used to agree on a common
secret key.

The protocol works as follows: to begin, a large prime number q and a primitive root
w ∈ GF q are specified, both of which may be publicly known. (GF q is used to denote
the finite field containing q elements. "Primitive root" mainly means that each element
can be represented as a power of w mod q ). Participants Alice and Bob (there may be
more, but we will stick with these two) each choose a random numbe xAr or xBthat lies
between 1 and q − 1. These numbers remain the secrets of Alice and Bob. Now Alice calcu-
lates the value

xA
yA = w mod q

while Bob calculates

xB
yB = w mod q

42
The resulting values are each communicated to the other partner. Because of the difficulty
of efficiently computing discrete logarithms, neither the partner nor any eavesdropper
(usually called “Eve”) can infer the secrets used. In the last step, Alice calculates the value

x
yBA mod q

and Bob calculates

x
yAB mod q

Both values coincide and can now be used as the common secret between Alice and Bob.

The protocol is simple to use and does not require a trusted third party. However, it should
be noted that no mutual authentication of the partners takes place during its course so
Alice does not know for sure whether it was actually Bob she agreed the secret key with,
and vice versa. In order to achieve authentication, additional protocol steps are needed.

Hybrid methods

In practice, hybrid methods are often used for encryption. This means that the key
required for symmetric encryption is exchanged beforehand using an asymmetric encryp-
tion method. This results in a secure key exchange, but a symmetric method can be used
for the actual encryption of the data. In general, symmetric algorithms are much faster
due to simpler bit operations that are closer to the hardware. However, a prerequisite for
the applicability of such a hybrid method is a public-key infrastructure, i.e., key pairs con-
sisting of public and private keys must be reliably and authentically available to the com-
munication partners.

Example: PGP

Pretty Good Privacy (PGP) is a software package that can be used to encrypt and digitally
sign both emails and files. Details of the software's history and scope of functions will not
be discussed here.

With PGP, asymmetric key pairs are generated by the users themselves: the private key is
stored in a password-protected manner, while the public key is transferred to a database
available on the Internet (or transmitted directly to potential communication partners). If
an email or file is to be transmitted confidentially to a communication partner, a hybrid
procedure is used: a symmetric key K is generated, and the file encrypted with K is trans-
mitted to the recipient - together with the key K , which is, however, encrypted with the
recipient's public key.

Example: SSL/TLS

The Secure Socket Layer (SSL) protocol, which is used and further developed today under
the name Transport Layer Security (TLS), is primarily responsible for establishing secure
HTTP connections, i.e. HTTPS connections.

43
 TLS does not use a "strict" hybrid procedure, insofar as the symmetric key is not transmit-
ted via asymmetric encryption, but only information that is used to generate the symmet-
ric key.

3.2 Digital Signature

An asymmetric cryptographic procedure is characterized by the fact that each participant
has a key pair consisting of a public and a private key. In the asymmetric encryption of
data, the public key of the addressee of the data is then used, who can restore the original
state of the data solely with the help of their matching private key.

The basic idea of a digital signature for data is to use one's own private key to sign the
data - the public key of the alleged creator of the digital signature can then be used to
check (verify) the signature for authenticity. This basic idea must, of course, be implemen-
ted by means of reliable and secure protocols using suitable cryptographic procedures.

A note on terminology: although we talk about “signatures”, these are not always consid-
ered as signatures in the legal sense. Different legislations have varying requirements on
when a digital signature can be considered a legal signature, and we can only hint at these
requirements in the current context.

Digital Signatures Using RSA

As an asymmetric encryption method, the RSA method has the special feature that you
can also first "decrypt" existing data using the private key (the result will usually be
unreadable) and then convert this result back to the original data with the associated pub-
lic key. The reason lies in the fact that multiple exponentiation is commutative, as follows:

d e
be = bd = be · d mod n

As before, e and n denote the public key, while d denotes the private key of a user.

d
This implies that b can be taken as the user's signature for the data block b, and both val-
d
ues together (i.e., b and b ) can be considered as a signed data block: anyone presented
d
with b and b can convince themselves of the authenticity of the signature by obtaining the
e
publicly available values e and n and convincing themselves that bd yields b again.

Digital Signature Algorithm (DSA)

The Digital Signature Algorithm (DSA) also is an asymmetric cryptographic method but not
derived from an encryption method like RSA. It is part of the Digital Signature Standard
(DSS) used in the US for digital signatures.

44
The mathematical basis - i.e., the reason why the corresponding private key cannot be cal-
culated from a public key easily - is the difficulty of determining discrete logarithms. We
will not go into technical details here - as with the RSA procedure, Euler's theorem plays
an important role here.

Using Hash Functions for Digital Signatures

The description of the digital signature so far does not yet contain the whole truth. The
reason is that it would actually be impractical to always consider the entire original data b
d
together with the signature b as "signed data" - this would mean that the signed data
would ultimately become about twice as large as the original data alone. As a way out of
this dilemma, a digital fingerprint is first created from the original data using a crypto-
graphic hash function (called a message digest), which is then signed. The hash function
used can or must then be known, of course, so that the signature can be verified by the
recipient.

In other words - to stay with the terminology used above for RSA - a signed data block b
d
consists of the pair b, ℎ b .

The following figures illustrate the creation of a digital signature and its verification.

Figure 6: Creation of a digital signature

45
 Figure 7: Verification of a digital signature

After this explanation of how digital signatures work and of the role of public and private
keys, the question naturally arises as to how this can be implemented in practice:

• How does a user get their keys?

• What tools are available that a "normal" user (who has not studied computer science)
can use to make or verify digital signatures?

In fact, there are different possible answers to these questions. A pure software variant is
offered by the PGP software package. Here, a user generates their own key pair, and the
private key is stored PIN-protected on the user's own computer system. If digital signa-
tures of the highest quality are to be provided in accordance with the EU's eIDAS (elec-
tronic IDentification, Authentication and trust Services) regulation, the keys are generated
by a trust center authorized for this purpose and the private key is handed over to the user
on a smart card; in this case, special software and a card reader certified by relevant
national agency must be used to create a digital signature.

Certificates and Public Key Infrastructure (PKI)

The processes described for creating and verifying digital signatures can, of course, only
work reliably if the public keys used are authentic, i.e., belong to the right people. After all,
what good is a carefully designed process for verifying a digital signature if the wrong pub-
lic key is used? This is where certificates come into play.

46
A certificate is a kind of "authentication" for a public key. The authentication consists of a
trusted entity whose public key is widely known "signing" that a certain public key
belongs to a certain person. One can illustrate this with the following simple scenario:

Assume that the head of state of your country possesses a key pair consisting of a public
and a private key as usual. Furthermore, the public key is known to every citizen or can be
retrieved on the Internet at any time. A certificate for the public key of citizen X is a data
record consisting of X's name, email address, and public key signed with the head of
state’s private key. Anyone can use the head of state’s public key to verify such a certificate
and thus convince themselves of the authenticity of X's public key.

In technical reality, the structure of the certificates used is precisely defined by the X.509
standard. In addition to the public key to be certified and its authentication (i.e. signature
by the entity issuing the certificate), data such as validity period, algorithms used, etc. are
included in the certificate. A certification authority (CA) is an institution that offers services
for issuing certificates. If a CA also generates and distributes matching key pairs, it is usu-
ally called a trust center.

In practice, certificate chains are usually used: user X's public key is authenticated by a
CA1, its public key by a higher-level CA2, and so on up to the highest authority, which is
widely trusted such as a national agency.

Any such certificate chain needs an initial certificate that is considered trustworthy, called
the root certificate. Therefore, applications such as browsers have a number of root certifi-
cates built in, which are considered trustworthy by the browser provider. Of course, the
whole chain breaks down if the root certificate refers to an organization that is not truly
trustworthy, such as a national intelligence agency, because of a break-in at the initially
trustworthy agency, or because an attacker has managed to inject a fake root certificate
into the browser.

The term public key infrastructure (PKI) has become established for the totality of compo-
nents that must be made available for generating and managing certificates. One usually
distinguishes three core components of a PKI:

• The Registration Authority (RA) receives requests for digital certificates and authenti-
cates the applicant.
• The Certification Authority (CA) issues the certificates.
• The Validation Authority (VA) provides a service to check the validity of certificates.

The software package PGP, which has already been mentioned several times, takes a dif-
ferent - more "grassroots" - approach: the community of users of the software certify their
public keys to each other, creating a "web of trust".

47
 3.3 Message Authentication Code
Message Authentication Codes (MAC) are an approach to confirm the authenticity and
integrity of messages. In plain language, a MAC is a checksum based on a symmetric key.
This checksum is appended to the message so that the recipient(s) (who also has/have the
key since this is a symmetric procedure) can verify the message.

The recipient thus can check that the MAC was created with the correct message and the
correct secret key, and thus knows that the message has not been altered (integrity) and
comes from the correct sender (authenticity). However, they cannot prove the latter to
third parties, because since the recipient also has the key, they could have created the
message themselves. Non-deniability of the message therefore cannot be achieved with a
MAC.

In contrast to a digital signature, a MAC is based on a symmetric procedure. The use of

MACs is therefore much more efficient than the use of digital signatures. In addition, a PKI
is not necessarily required, and there is no binding to a specific person. For this reason,
MACs are usually preferred in use cases where non-deniability is not important, for exam-
ple as a component of TLS.

Analogous to digital signatures, however, the confidentiality of a message cannot be

ensured by the use of MAC alone, since the message itself is transmitted in plain text. If
this confidentiality is also required, the message must be transmitted in encrypted form.

From a technical point of view, the procedure is often implemented using cryptographic
hash functions, where the key k and the hash function h are combined in different ways to
form MAC M, k of the data block M :

1. Encryption of data in the CBC mode of a block cipher using the relevant key k. The
final block serves as the result MAC.
2. Append the key k to the data and form the hash value of the data thus expanded as
MAC, i.e. MAC M, k = ℎ M, k .
3. Twofold application of the hash function ℎ to the data M extended by the key k modi-
fied using two pre-defined bit sequences.

Variant 1 often uses the DES method. Variant 2 is used with MD5 as the hash function
under the name MD5-MAC (also known as Keyed MD5), for example as part of SSL/TLS.

Variant 3 is called Keyed-Hash Message Authentication Code (HMAC), as used with IPSec
and with TLS. In the following, this variant will be briefly outlined in slightly simplified
form.

Keyed-Hash Message Authentication Code (HMAC)

Assume a cryptographic hash function ℎ with an output block length of r bytes and a key k
that also consists of r bytes. Two special sequences consisting of r bytes are used:

• ipad is the r-fold repetition of the byte 00110110

48
• opad is the r-fold repetition of the byte 01011100

The HMAC of a message M is then formed as follows:

HMAC M k = ℎ k⨁ opad ℎ k⨁ ipad M

The symbol ∥ describes the concatenation of strings.

Figure 8: Creation of HMAC

This relatively complex and unintuitive structure of HMAC prevents certain attacks that,
for example, attempt to append additional information to the message at the beginning or
end. However, this aspect will not be discussed in detail here.

Although the MD5 algorithm is generally no longer recommended as a cryptographic hash

function, to date there are no objections to its use within an HMAC; no security weak-
nesses have yet been discovered here.

In practice, when using Message Authentication Codes, the corresponding protocols in

which they are embedded must of course take care of the exchange or generation of the
necessary keys. Such a key agreement is possible between two communication partners,
but also for an entire group.

49
 3.4 Steganographic Methods
Steganography deals with hiding the very existence of a message, rather than just disguis-
ing the information content through encryption. A simple example is familiar to many
people from childhood: one can use some liquids as secret ink, so that the composed
message becomes visible only on exposure to light or by heating. Another example is lin-
guistic agreements that groups of people make to hide the content of conversations from
overhearers.

Steganographic methods also play a role in modern digital information technology.

Strictly speaking, steganography has nothing to do with cryptography to begin with - a
message that is hidden does not need to be encrypted. However, in the case of digital
watermarks, which will soon be discussed, both areas come together. For the time being,
however, we will stay with pure "hiding".

Multimedia formats, for example digital images, are very suitable for hiding information.
As is well known, digital images are represented by dots (called pixels), each of which is
described by one or more bytes: in a grayscale image, one byte per pixel may suffice (giv-
ing 256 possible shades of gray), while in a color image, three bytes per pixel are often
used to indicate three basic values for red, green, and blue by one byte each. The basic
steganographic principle is now to use the "least significant bit" (or LSB) of each byte as a
hiding place for the secret information; the resulting changes are usually not perceived by
the human eye viewing such a manipulated image. (Sufficiently sophisticated steganogra-
phy software will not manipulate particularly important pixels - for example, those mark-
ing a boundary line).

Example: Hiding a letter in three pixels

The ASCII encoded letter "i" - i.e. the byte 01101001 - is to be hidden in three consecutive
pixels of a 24-bit image. The original pixels are shown in the next figure. The 8 bits of this
byte are now each hidden in the last bit of the pixel coding, whereby the last pixel is not
needed. In the following figure you can see which pixels resulted after inserting the letter -
only three bytes had to be changed (shown in bold), because the remaining LSBs already
had the desired value.

It is obvious that compressing a steganographically manipulated image can cause the hid-
den information to be lost - so caution is required here. There must be no loss of data
when compressing, as happens for example with the jpeg format. The format bmp does
not cause a problem here, also the well-known "zipping" does not destroy the hidden
information.

Table 1: Coding of three pixels

Original coding of three pixels

red green blue

Pixel 1 01001110 11101010 11001001

50
 Original coding of three pixels

Pixel 2 01001110 11101111 11001111

Pixel 3 01001001 11101111 11001001

Three pixels with hidden information

red green blue

Pixel 1 01001110 11101011 11001001

Pixel 2 01001110 11101111 11001110

Pixel 3 01001000 11101111 11001001

Messages can be hidden not only in digital pictures and videos. For example, the encoding
software used to digitize telephone conversations can also be used to convert ASCII char-
acters or other data in the LSBs of the transmitted voice bytes.

Digital watermarking is not just about inserting any hidden information into data - the
information is also intended to protect the data object from modification or misuse. In
other words, digital watermarks make imperceptible changes to multimedia data in a way
that enables the detection or tracking of misuse. One goal can also be to identify the crea-
tor of a file - then it is a copyright watermark.

A simple example

The digital signature of the file's creator is embedded steganographically (i.e. hidden and
imperceptible) in a multimedia file. A copy of the file to which changes have been made
can thus be shown to be a forgery.

In practice, a variety of methods exist for creating digital watermarks that are far more
sophisticated than the simple example above. For example, access to the embedded infor-
mation can also be controlled through the use of a secret key. The watermarks can even
be constructed so that they are not lost by common conversions of the medium (such as
digital-to-analog conversion or clipping of a picture). If we include the legal dimension
(copyright, copyright protection) in this topic, we now speak of digital rights management
(DRM).

SUMMARY
There are many different types of application of basic cryptographic
functions. For any practical application, concrete cryptographic building
blocks are embedded in suitable protocol flows.

51
 One important type of application of cryptography is key exchange. A
number of general procedures exist here, based on symmetric and
asymmetric cryptographic building blocks. Another important applica-
tion are digital signatures, for which asymmetric procedures and crypto-
graphic hash functions are used in combination.

The authenticity and integrity of messages can be secured with a mes-

sage authentication code (MAC), which is more efficient and easier to
use compared to digital signatures. However, MACs do not support non-
deniability and therefore cannot be used if evidence of certain activities
towards third parties is required.

Steganography is not about making data unreadable, as is the case in

cryptography, but about hiding the very existence of the data. Among
other applications, steganographic techniques are used for digital water-
marks.

52
 UNIT 4
AUTHENTICATION

STUDY GOALS

On completion of this unit, you will be able to ...

– discuss the usage of passwords for authentication.

– describe the concept of challenge-response protocols.
– illustrate the role of certificates in authentication.
– demonstrate the use of biometric procedures for authentication.
– explain the usage of smartcards for authentication.
 4. AUTHENTICATION

Introduction
This unit discusses the most important procedures for authentication, i.e. checking the
authenticity of objects and subjects in the context of computer systems and users of these
systems. Three fundamental forms of authentication are addressed: authentication by
knowledge, by possession, and by biometric properties.

In the case of authentication by knowledge, proof is provided by demonstrating knowl-

edge of a certain secret – a classic example is the use of passwords. Cryptological methods
come into play when storing or transmitting such secrets. Authentication using smart-
cards is an example of authentication by possession, which is usually supplemented by
authentication by knowledge (PIN). Typical examples of authentication by biometric prop-
erties include the use of fingerprints or of iris scans.

We speak of two-factor (2FA) or multi-factor authentication (MFA) when combinations of

several techniques are used, where one usually expects that these different factors are
based on different fundamental forms of authentication. If a system offers several services
for which authentication is required, single sign-on describes the concept where a user
can use all services after a single authentication.

4.1 Passwords and public key certificates

Passwords are the "classic" form of authentication. The usual rules for choosing pass-
words - i.e. "not too short", "combination of letters and other characters", etc. - will not be
discussed here. Many systems today do not accept "bad" passwords chosen by users at
all, although the rules used for judging whether a password is bad differ a lot. Well-known
recommendations for defining suitable password policies can be found in (NIST 2017, Ch.
5.1.1).

A problem arises from the fact that, on the one hand, users should not choose the same
password for several systems, but on the other hand, it is impossible to remember many
passwords. The result is often hidden pieces of paper on which passwords are written
down. A solution to this problem can be password safes - these are small programs or
apps that are protected by a password and have the other passwords stored.

Password storage and transmission

Password-based authentication methods are generally used for personal computers and
workstations. The respective computer system must of course store the passwords
assigned to the individual users securely so that they cannot be accessed without authori-

54
zation. The use of cryptographic hash functions is common here, so that even someone
who gains unauthorized access to the stored password file cannot gain access to the pass-
words in it.

A simple example

For access to a web service John Smith has the password "Manchester City", Jill Jones has
the password "Manchester United". In this case, the following data are stored:

1 John Smith| 5c806f80b25eae641a599d5b9ba5150f126a581199a802b4eca22

dec5cc4f5661015d8054ef0b0c8d6182b8ffb6ab0e6d85c0016f14e30821d5008
8acca862ab
2 Jill Jones| 8b133f24bea457a243d1b6a1298d450b86890aa54711fe7131b2b
8c713dc6ea9ebaf78ddc4bfe0de2ed9e783cb5c81de14b120faa476fdc3448d21
bde820d421

Here, the usernames are stored together with the SHA3 hash value of the password. Note
that, even though the two passwords start with the same letters, the stored hash values
are completely different.

If either user now enters their name together with their password, the system forms the
SHA3 hash of the entered password and compares the result with the stored value – if the
values match, the user is considered authenticated.

Due to the properties of cryptographic hash functions, it is practically impossible to

deduce from the hash value the password that led to this hash value – yet it may be gener-
ally known without any problems that SHA3 was used here. Someone who gets hold of
this password list would therefore have to spend a huge computational effort to exploit
this – they would have to compute the SHA3 hash of possible passwords themselves and
hope to catch one of the hash values in the list. Such a brute force attack on its own is
unlikely to be successful in this case. However: If such an unauthorized user were to start
with meaningful words (e.g. football teams) when trying them out, or were to continue
trying out initially known words (such a thing is called a dictionary attack), they could be
successful if the legitimate user did choose such a weak password, as done in the exam-
ples above.

To make dictionary attacks using rainbow tables more difficult, many applications today Rainbow tables
(e.g., also password storage in UNIX) use a "salt". This is a number (e.g., consisting of 12 are precomputed lists of
possible passwords
bits) that is appended to the password before the hash function is applied and then stored together with their hash
together with the hash value. First, this ensures that different "hashed" passwords are values. These usually con-
stored even for users who happen to have chosen the same password. In addition, the tain all possible pass-
words up to a certain
effort required for a dictionary attack is increased enormously. length, and/or likely can-
didate passwords.
A relevant question is, of course, whether the password is transmitted in clear text or
encrypted when authenticating via a communication network (for example, when authen-
ticating a user to a web server) – and if so, how exactly this is implemented. Different var-
iants exist here in practice, which will be discussed later.

55
 System-Generated Passwords

In order to avoid the possible weaknesses of user-selected passwords from the outset,
some systems do not let the users generate their passwords but generate it for them. How-
ever, such system-generated passwords often have the disadvantage that they are difficult
for the user to remember, which again leads to the problem of secure handling or storage.
System-generated passwords are often assigned for access to remote computers or serv-
ers. The assignment of a PIN for various cash cards uses the same concept.

Example: Girocard PINs

Until a few years ago, the PIN for a girocard was calculated from the data stored on the
card. It therefore did not have to be stored directly on the card; rather, when the card was
used – at an ATM, for example - the PIN to be entered was calculated by the ATM and com-
pared with the PIN entered by the user. For the calculation, the ten-digit account number,
the last five digits of the bank routing number and a one-digit card sequence number were
written in succession and converted into a 64-bit value. This was then encrypted using the
3DES method, with the key used varying with the bank that issued the girocard. Finally,
certain bits were selected from the 64-bit result to form the four-digit PIN.

In the new method used today, the user can choose the PIN themselves, which is then
stored on the card in 3DES-encrypted form. During verification, the ATM must also 3DES-
encrypt the PIN entered for comparison, and the key to be used is derived from other data
stored on the card.

One-Time Password

One-time passwords are a generalization of the one-time pad that is based on a password
consisting of a sequence of random symbols, where the password is at least as long as the
message to be encrypted. At first glance, it doesn't seem like a sensible idea to set a pass-
word that can only be used once for authentication – when you authenticate again, you
need a new password, which also has to be agreed upon again somehow. One-way func-
tions are the key to solving the problem. With their help, such OTP (one-time password)
procedures can be designed.

Example: the S/Key method

The S/Key method of multiple authentication with one-time passwords is commonly used
in UNIX environments to allow clients to gain access to a remote server. The procedure
consists of an initialization phase, which must be run through once, and the individual
authentication steps, which must then be run several times during login operations.

First, a system constant N and a cryptographic hash functionℎ are fixed. In the initializa-
tion phase, the user first forms an initial value s from their "root password", which they do
not have to transmit to the system, and a value provided by the system. Then they form
the N -fold application p0 of the hash function ℎ to this initial value:

p0 = ℎ ℎ …ℎ s … = ℎN s

56
Next, the user passes the value p0 to the system, which completes the initialization phase.
Subsequently, the user can now register N times with the system by submitting the val-
ues:

pi = ℎN − i s for i = 1, ... N

An unauthorized person cannot predict the next password, since this is always a preimage
(under the function ℎ) of the previous password.

In practice, a number of variants of OTP procedures exist. Unlike S/Key, the hash function
is sometimes not used directly to generate multiple one-time passwords. One possibility is
to add a counter or a time-based factor to the user's secret s, which is also known to the
system, before applying the hash function to generate the password or an additional
"AccessCode". An example of the latter variant is the Google Authenticator for authentica-
tion on the web.

Public Key Certificates

As explained before, certificates ensure the authenticity of public keys. This can be exploi-
ted in a simple way for authentication purposes.

A simple scenario

Alice wants to authenticate herself to Bob in a communication network. To do this, Alice

sends Bob her claimed identity "Alice" together with a public key and a certificate from a
trusted certificate issuer for this public key. If Bob has the public key of the certificate
issuer, he can verify the authenticity of the certificate. If Bob now sends a message encryp-
ted with this public key to Alice, only Alice will be able to read it even though an attacker
may be able to intercept the message.

This is the principle used for SSL/TLS authentication. Note however that to use such
authentication with certificates, a public key infrastructure must be available.

Types of Attacks on Password Authentication

There a several attack types on authentication methods based on passwords or other

forms of common secrets:

• Passwords may be stolen from the server. As experience shows, this happens quite
often, and in such cases the attackers usually gain not individual authentication data
but large numbers of such data. The service haveibeenpwned.com collects published
data from such breaches, and as of April 2022 lists a total of more than 11 billion
accounts for which password data have been stolen – more than there are humans on
earth. This is not necessarily a problem if the password lists were adequately protected,
storing only hash values including salt. In many cases, this unfortunately was not done,
and in particular users who used the same password for different services are now
easily attacked.

57
 • Passwords may be stolen from the client, often via some malware attacks or social
Social Engineering engineering.
Methods used by attack- • Passwords may be stolen while in transit, for example if they are transferred as part of a
ers trying to trick people
into performing inade- URL without encryption.
quate actions such as
revealing sensitive infor- There are many more forms of attacks which however do not scale well and therefore will
mation, providing unau-
thorized access, or down- not be considered here.
loading and executing
malicious files that look
benign.

4.2 Challenge-Response and Zero-

Knowledge Protocols
Challenge-response protocols can be regarded as a generalization of password-based
authentication. The user's "knowledge" is not transmitted directly to establish authentic-
ity; instead, the system asks the user a question ("challenge"), and the user must use their
knowledge to answer it ("response"). The advantage of this procedure is that these ques-
tions (and the expected answers) can vary with different authentications, so that – unlike
with a password procedure – an attacker is not able to use intercepted information
directly for authentication.

Example: Challenge Response using AES

The secret knowledge shared between user A and the system consists of an AES key kA.
During authentication, A first transmits their (claimed) identity "A". The system now gener-
ates a random number rand and sends it to A. A encrypts rand using kA and transmits the
result X = AES rand, kA to the system. The latter performs the same encryption with
result X′. If X = X′, then user A is considered authenticated.

Of course, any other symmetric encryption algorithm may be used instead of AES. It is also
possible to use an asymmetric algorithm – in this case the user uses their secret key to
calculate the response (as in the case of a digital signature); the advantage of this variant
is that the system does not need any secret shared with the user.

A well-known example of challenge-response procedures is used in modern digital mobile

networks. Here, a two-stage procedure is used: when the mobile device is switched on, the
user first authenticates themselves to the SIM card used by the device by entering a PIN.
This is followed by a challenge-response process with symmetric encryption between the
SIM card and the network. Complex protocols ensure that a SIM card can also log on to a
"foreign" network that does not even know the secret key – further details are not dis-
cussed here.

Zero Knowledge Protocols

Zero knowledge protocols can be regarded as special types of challenge-response proto-

cols, since they also involve a challenge and response. In all of the authentication meth-
ods described so far, the user who is to be authenticated must reveal their secret – albeit

58
in encrypted form. Note that even when a certificate is used, the public key provides infor-
mation about the secret (the associated private key), although this is difficult for an unau-
thorized person to exploit.

In contrast, the basic principle of a zero-knowledge protocol sounds incredible: you can
prove possession of a secret without revealing even the smallest piece of information
about that secret! The proof is always given only with a certain probability. The "trick" is
then to perform this procedure again and again in several independent rounds. This way,
the probability that the person to be authenticated successfully survives all rounds with-
out being in possession of the secret can be made arbitrarily small.

The precise mathematical definition of the zero-knowledge property would go beyond the
scope of this course and therefore will not be discussed here. However, the following easy-
to-understand analogue shows that such protocols are possible: in the 16th century, the
Italian mathematician Tartaglia announced that he had found an algorithm to solve any
cubic equation. Since this was his business secret, he did not want to make the algorithm
public, but he could easily prove that he had indeed found such an algorithm by solving
any cubic equation given to him.

The best known zero-knowledge method is the Fiat-Shamir protocol (first published in
1986), which was later extended to the Feige-Fiat-Shamir protocol. It is based on the diffi-
culty of drawing discrete square roots modulo a large natural number n.

The Feige-Fiat-Shamir Protocol

In preparation, there is first a key generation phase in which the secret assigned to A is
determined. To do this, A forms the product · n = p · q of two large prime numbers p and q
(as in the RSA process) and announces it publicly, while p and q remain secret. (In practical
applications, this is done by a trusted entity or provider.) Next, A chooses as secret a num-
ber s ≤ n − 1 which is coprime with n and computes the value v = s2 mod n which is
also made public. This completes the key generation phase.

Note that s cannot be easily computed from v; the authentication of A is done by proving
to know s. If A wants to authenticate themselves to B, they go through several rounds of
the following procedure:

• A chooses a random number r between 0 and n-1 and computes x = r2 mod n

• A randomly chooses z = x or z = − x mod n and sends this value to B.
• B randomly chooses a bit b (i.e., 0 or 1) and sends it to A.
• If A receives the bit b = 0, A sends the value y = r to B; if A receives b = 1, A sends the
value y = r · s mod n .
• B now verifies A's response in the following manner: if B previously sent the bit b = 0,
then y2 mod n must be equal to z or −z; if b = 1, then y2 mod n must be equal to
z · v mod n or −z · v mod n .

59
 As can be seen, A only has to prove they know s in the case b = 1. Thus, an unauthorized
person pretending to be A could survive a round with probability ½ . By repeating the
process several times, the success probability of an unauthorized person can thus be
made arbitrarily small.

Note: The protocol would not work if the selection of the bit b would be omitted and A
would always (as in the case b = 1) send the value y = r · s mod n . In this case an
impostor could claim to be A by starting the process with x = r2 /v mod n .

The Fiat-Shamir method was used in the 1990s – soon after its publication – on smartcards
for pay TV. The obvious advantage of the method is that the verifier does not have to share
a secret with the verified party (as is generally the case with public key methods); in addi-
tion, it does not require such complex computing operations as is the case with the RSA
algorithm. However, zero-knowledge procedures have not yet been used on a large scale
in practice.

FIDO2 Authentication

FIDO2, successor of the Universal Second Factor U2F, is a joint project between the FIDO
Alliance and the W3C that intends to set up an easy-to-use but strong authentication for
the web. To achieve this goal, it introduces the concept of an authenticator which is a
hardware or software component with two core functions:

• User verification (which is not part of the FIDO2 standard): the authenticator verifies the
user identity, allowing many different approaches to doing so, for example using finger-
prints or a PIN.
• Authentication towards the service, in FIDO2 called the “relying party”, using a public
key challenge-response protocol. The secret keys are stored securely within the authen-
ticator and never have to leave it, making it easy to keep them confidential.

The fact that the secret key never leaves the authenticator implies that it is impossible to
create a backup of the authentication data. Relying parties must therefore allow the possi-
bility to register with several alternative second factors, because otherwise a loss of an
authenticator would permanently lock the user out. FIDO2 users, on the other hand, must
use this possibility and register multiple second factors, possibly but not necessarily mul-
tiple FIDO2 authenticators.

The following figure shows the basic structure of FIDO2.

60
Figure 9: FIDO2 Architecture

At its core, FIDO2 contains two main protocols: the Client To Authenticator Protocol (CTAP)
– as its name suggests – defines the communication between the client and an external
authenticator. The WebAuthn standard defines an API that allows users to authenticate
themselves in the web browser towards the server / relying party, based on the (internal
or external) authenticator.

By separating user verification and authentication, the architecture allows the user verifi-
cation to be performed in some form that is convenient for the specific user concerned,
while at the same time providing a very secure protocol for the communication between
the authenticator and the service (relying party) to be used. In particular, the relying party
does not have to store any common secrets such as user passwords, but only the public
keys of the users. As a result, it is no longer possible to steal authentication data on a large
scale from the relying party.

The authenticator generates a new key pair for each relying party, thus ensuring that users
cannot be tracked across different relying parties based on their public key.

To ensure security of the authenticator, it can be implemented as an external authentica-

tor, usually a USB token, or in software based on some secure platform, as for example
available on current versions of Windows and Android.

4.3 Biometric Authentication

In biometric techniques for authentication, characteristics of individuals are recorded
(usually automatically via sensors) and typically stored in a database. Thanks to advances
in biometric technology, this is now possible on small devices, for example, using finger-
print instead of PIN to unlock the SIM card on a smartphone. Once authentication is nee-

61
 ded (for example, because a person wants to enter a protected area), the same biometric
property of the person is captured again and the result is compared with the data stored in
the database. If there is a close match, the authentication was successful.

Biometric features used today include the following:

• Body size,
• iris or retina features,
• fingerprint,
• facial features,
• hand vessel structure/vein recognition,
• hand geometry/hand line structure,
• voice and speech patterns,
• handwriting,
• typing pattern on keyboards,
• body odor,
• DNA.

There is always a learning phase in which the biometric features are recorded as a refer-
ence sample in digital form and stored in encrypted form. When the biometric system is
used, a current sample pattern is recorded and compared with the reference pattern. The
system then has to decide whether the similarity between the two samples is sufficiently
high and authentication is successful.

A general difficulty of biometric methods is that characteristics of persons change a little

over time or between different measurements. In the example of facial recognition, one
has slight changes due to aging, but also effects such as with/without glasses or with/
without beard, or due to different lighting or different positions. The quality of the analy-
sis and evaluation algorithms used therefore is of eminent importance.

In effect, this means that since two digital patterns of a biometric feature are never identi-
cal, an exact match can never be achieved! The features can therefore not be tested for
equality, but for sufficient similarity. The inevitable consequence of this is that biometric
systems can only work correctly with a certain probability. Two types of errors can occur:
either an unauthorized person can be falsely accepted as an authorized person, or an
authorized person can falsely be rejected as unauthorized. It is therefore natural to judge
the quality of a biometric procedure according to the following two criteria:

• False Acceptance Rate (FAR): This is the rate of unauthorized persons who are incor-
rectly accepted as authorized persons.
• False Rejection Rate (FRR): This is the rate of authorized persons who are falsely rejec-
ted.

62
Figure 10: Sensitivity of biometric authentication and resulting error rates

In most applications, a false acceptance is considered worse than a false rejection. A false
rejection implies that the user has to try to authenticate one more time, while a false
acceptance means that an unauthorized used gets access to the system. However, if legiti-
mate users are rejected repeatedly, they may consider this as unacceptable, especially if
the system has low security requirements. It therefore is important to find an adequate
compromise between security and usability of the system.

Example: Biometric Passports

Since about 2005, many countries have started issuing “biometric passports”, i.e. pass-
ports storing biometric data of the passport holders, with about 150 countries as of 2019
(Thales, 2022). The worldwide introduction of such biometric passports was initially
demanded by the USA after the attacks of September 11, 2001, and was later enforced.

The passports contain a microprocessor chip on which the biometric data are stored, usu-
ally fingerprints and a digital photo of the holder. These data can be accessed using con-
tactless technology, for example RFID chips. Radio-frequency identi-
fication (RFID)
is a contactless technol-
The advantages of biometric methods for authentication are obvious: because they are ogy that uses electromag-
tied to individuals, simple and quite secure authentication can be carried out without hav- netic fields to automati-
ing to use usernames, passwords or even any secret keys. However, other disadvantages – cally identify and track
tags that are attached to
apart from false acceptance or false rejection – must be mentioned: Absolute security objects such as passport.
must be guaranteed for the stored data, since these cannot simply be replaced after unau- This is often used in logis-
tics, for example allowing
thorized access, in contrast to passwords. It may also not be clear what happens to the
to identify all goods on a
data generated during authentication (e.g., during a passport check in another, possibly pallet without unloading.
untrustworthy, country).

63
 Finally, the risks to physical integrity must also be pointed out: It cannot be ruled out that
criminal violence will make use of "human keys" to gain access to property and money.
Attacks are also possible with "softer" methods: Security researchers were able to recon-
struct politicians' fingerprints from high-resolution photos of their hands.

Conclusion: As in many other areas, there is a constant race between security technology
development and new approaches to unauthorized attacks in biometric techniques.

4.4 Authentication in Distributed Systems

The authentication techniques discussed so far are also relevant within authentication
protocols that run in environments with distributed systems such as client-server architec-
tures. Direct and exclusive use of simple authentication mechanisms such as passwords,
certificates, etc. is usually not sufficient here. For example, passwords should be transmit-
ted in encrypted form - but then the question immediately arises of how the keys are man-
aged and transmitted. Another problem: If there is some kind of "authorization tokens" for
access to services/servers, the danger of a "replay attack" (i.e., unauthorized reuse) must
be ruled out. In short, one has to come up with more complex protocols to implement
authentication and key management in a distributed scenario.

In the following, we will first introduce RADIUS, which has established itself as the de facto
standard for authentication for dial-up connections to a computer network. The authenti-
cation and key distribution system Kerberos for distributed systems is then discussed.

RADIUS

RADIUS stands for Remote Authentication Dial In User Service – a name that describes
quite well its functionality: authentication of users who access the Internet via a dial-in
node of a service provider, such as Integrated Services Digital Network (ISDN), Virtual Pri-
vate Network (VPN), Wireless Local Area Network (WLAN), or Digital Subscriber Line (DSL).
The dial-in node acts as a RADIUS client that receives the user's authentication data (usu-
ally username and password) and forwards it to a RADIUS server using the RADIUS proto-
col. Encryption of the transmitted data is not part of the protocol, but the password is pro-
Pre-shared key cessed using a pre-shared key agreed between the RADIUS client and server and using
A pre-shared key (PSK) is the hash function MD5, and conversely can also be recovered from this data. (Today, an
a secret or key that is
shared in advance updated variant of the RADIUS protocol exists, called Diameter, which uses IPSec and TLS,
between two or more par- but this is not yet widely used ).
ties using a secure chan-
nel. This is for example
used in Wi-Fi Protected The authentication of the user then proceeds as follows:
Access (WPA) where all cli-
ents and access points
• The user establishes a connection to the dial-up access server (using one of the techni-
share the same key.
ques described above).
• Once the connection is successfully established, the user submits his authentication
data (name and password).

64
• Acting as the RADIUS client, the dial-up access server uses the RADIUS protocol to trans-
mit this data to the RADIUS server (or initially to a proxy server if there are different
"RADIUS zones"). This then checks the authentication data by querying a user database
and transmits the result of the check back to the RADIUS client.

Kerberos

The name "Kerberos" is taken from Greek mythology, where it refers to a three-headed
dog that guards the entrance to the underworld. The Kerberos system was originally
developed as part of a project at MIT in Boston (in cooperation with the companies IBM
and DEC) and uses the Needham-Schroeder protocol for symmetric cryptosystems.

Kerberos is based on the client-server model, in which the Kerberos server is involved in
addition to the client and the server. All actors – users, clients and servers, are referred to
as principals in Kerberos. With regard to authentication, single sign-on is supported. A cli-
ent may only use a server service if it can present the server with a certificate of authentic-
ity, called a ticket.

After the user of a system using Kerberos services has logged on to their workstation, the
Kerberos client first requests a TGT (ticket-granting ticket) from the Kerberos server KDC
(Key Distribution Center), which is divided into an AS (Authentication Server) and a TGS
(Ticket-Granting Server). With the TGT received, the client is then able to request addi-
tional tickets for services: The user can submit their TGT to their TGS to obtain a ticket for
claiming a service offered by a server within the same administration area. In doing so, a
TGT can be submitted multiple times during its validity period (typically: a few hours) –
thus you have the single sign-on. The basic procedure is shown in the next figure.

65
 Figure 11: Sequence diagram: Kerberos authentication

The Authentication Server shares a secret key Kp with each principal P as the basis of the
protocol processes. A ticket, which contains the username and the network address of the
client as well as the session key and timestamp, is always encrypted with the key Ks of the
issuing server. Version 4 of Kerberos uses only DES as the encryption method, which
means that this version can no longer be considered secure today; version 5 added other
possible methods such as AES and RC4. Further details of authentication and communica-
tion with the individual services will not be discussed here. Both versions 4 and 5 of Ker-
beros have been taken up and implemented by various manufacturers, and implementa-
tions are freely available. Kerberos is also included in the widely used Active Directory
service under MS Windows.

66
4.5 Identities through smartcards
In the digital world, people, but also devices and other objects, have an identity that must
be proven in a trustworthy manner on certain occasions. When it comes to people who are
to be identified in a real environment using digital technology and in an automated man-
ner, smartcards can often be used. For secure identification of users on the Internet, pro-
prietary procedures are used.

Many countries, including for example Germany, have adopted some strategy to introduce
smartcards to support electronic automated authentication and the use of digital signa-
tures. Typical examples are electronic health cards, electronic ID cards and passports, and
electronic tax returns.

What exactly is meant by a smartcard?

There have been various stages in the development of smartcards, and they are still used
in different forms today. This development started with pure memory cards (example:
phone card) and then moved on to smart memory cards that can contain "hardwired"
functions such as PIN storage and verification (example: an access card for specially
secured door), or genuine smartcards with their own microprocessor. Some cards also
include additional peripherals such as a keyboard, display or fingerprint sensor.

There are numerous possibilities for the exact structure of a smartcard. The specifications
for this are laid down in the standard ISO/IEC 7816. These specifications concern the exact
dimensions, the arrangement of the electrical contacts, the physical properties of the sig-
nals that can be exchanged with the card, and the applicable transmission protocols. It is
also possible for data to be exchanged via radio instead of contacts. A smartcard can also
have a magnetic strip, but this does not store any security-relevant data.

When a user is authenticated with the aid of a smartcard, a distinction is generally made
between three phases:

• Authentication of the user against the smartcard,

• Authentication of the smartcard against the target system (e.g. personal computer or
card reader),
• Authentication of the target system against the smartcard.

In practice, the third step - authentication of the target system against the card - is often
omitted.

Authentication of the user against the smartcard

This first step is usually based on the user entering a PIN. The entry is made at a reader or
directly on the card if it has its own keypad. In the first case, the entered PIN must be
transmitted to the card so that its microprocessor can check the validity of the entry. The
input is compared with the expected PIN, which is stored in the card's EEPROM (Electri-
cally Erasable Programmable Read-Only Memory), possibly in encrypted form. A counter is

67
 kept of the number of failed attempts, usually three failed attempts lead to blocking of the
card. Some cards (e.g., SIM cards in mobile communications) can be unblocked with a
PUK (PIN Unblocking Key).

Instead of PINs, biometric techniques are increasingly being used. Since special readers
are used here (such as fingerprint scanners), the data collected by the device must be
compared with the user's reference data stored in the card, and this comparison may take
place in the device. Clearly, the trustworthiness of such devices is again of great impor-
tance.

Authentication of the smartcard against the target system

As a rule, challenge-response protocols are used for this step. For symmetric encryption,
Global System for the standard algorithms such as AES (e.g., under the designation A3 in GSM networks),
Mobile Communications while RSA is typically used as an asymmetric method.
(GSM)
is a standard for second-
generation (2G) protocols Smart ID cards
for mobile communica-
tions, supporting both
voice communication (tel- Many countries have introduced smart ID cards, often integrated into the national ID card,
ephony) and data com- in order to allow citizens to identify themselves for relevant services. In particular, such ID
munication. Today, it has
cards can often be used to allow citizens to identify themselves for online services, or for
largely been replaced by
UMTS (3G), LTE (4G) and digital signatures.
partly by 5G but GSM net-
works are still available in
large parts of the world.
Typically, an online service provider who wants to access data from such an ID card must
present an authorization certificate for this purpose, which they must obtain from a
defined national agency.

SUMMARY
The most common way of authentication in IT is based on the use of
passwords. In addition to simple passwords, one-time passwords and
system-generated passwords are also in use. Great attention must
always be paid to the secure generation and transmission of passwords.
If asymmetric key pairs are available, certificates for public keys can also
be used for authentication.

As a rule, challenge-response or zero-knowledge procedures offer

greater security than passwords. Both types of procedure have in com-
mon that no secret has to be presented or transmitted directly (not even
in encrypted form).

More and more, biometric procedures are also being used in practice, in
which physical characteristics or behavioral patterns of persons are used
to recognize individuals.

68
In distributed systems, complex protocols are used for the purposes of
mutual authentication and the allocation of authorizations for the use of
services - common examples are Radius and Kerberos.

Smartcards are often used for proving identity in a physical environment

(example: access control for restricted rooms). An important application
of smartcards are ID cards issued by national governments.

69
 UNIT 5
SECURITY OF SINGLE COMPUTERS

STUDY GOALS

On completion of this unit, you will be able to ...

– describe the concept of malware

– discuss the purpose of cookies and their security issues
– explain the Microsoft “File Encryption Service”
– demonstrate what needs to be considered in securing web servers
 5. SECURITY OF SINGLE COMPUTERS

Introduction
This lesson is dedicated to securing individual computers. This essentially includes access
protection and protection against the harmful effects of software. These effects can come
from malware running on the machine or from incorrectly accepted malicious user input.
The latter plays a particularly large role with web servers - the root cause of the problems
is ultimately a lack of care in implementing the appropriate input interfaces.

Generally, in this lesson, the term "computer" refers to an operating system installation on
a hardware device, not the device itself. In this sense, several "computers" - even of com-
pletely different types - can be installed on one device.

5.1 Malware and Cookies

Malware

What methods can be used to attack a computer? More generally, what threats exist?

Today, IT systems are mainly attacked with the help of software. In contrast, attacks via
hardware, such as exploiting compromising radiation or stealing a notebook, are less sig-
nificant. The following subdivision will be used for threats via software (in the discussion
of this issue, other subdivisions are also encountered, although the basic phenomena con-
sidered are the same):

• Malware (malicious code)

• Bugs

The term malware covers viruses, worms and Trojans. All of these are programs that exe-
cute specified functions that are hidden from the user or are not desired by the user in any
case. A virus requires a "host program" to execute, and the execution of the malicious
functions may depend on a trigger. In contrast, a worm is an independent, executable pro-
gram with the ability to reproduce. Finally, a Trojan or Trojan horse is a program that pre-
tends to be "innocent" but contains additional hidden functionality.

If one of these damaging programs specifically exploits a particular vulnerability in com-

puter systems, this is known as an exploit. In the "daily business" of IT security, the term
zero-day exploit is often used. These are exploits that take advantage of a vulnerability
that has been discovered (and is known at least in certain circles) before the manufacturer
of the system has had the opportunity to eliminate the problem with a patch.

72
In contrast to malware, one speaks of a bug if the misbehavior of software results from an
unintended programming error. Such a programming error can be a "stupid" mistake (e.g.,
using a period instead of a comma in an instruction) or, for example, an insufficient check
of a user input that is forwarded to another process.

As a generic term for malware and bugs, the term “software anomalies” is commonly
used.

A related topic that may or may not be a security problem is “mobile code,” which has
gained a lot of importance in recent years, especially in connection with smartphones.
This term refers to complete programs that are transferred to a computer via a communi-
cations network and executed there. Mobile code as such is not a problem, but applica-
tions that contain harmful functions ("malicious code") are increasingly being circulated
in the process. Mobile agents are special forms of mobile code; they "wander" from one
node to the next in a communications network, are executed there, in turn perform func-
tions, may themselves be modified, and are then forwarded.

This leads to various types of security threats associated with mobile code:

• The code can be attacked in transit, i.e. modified without authorization.

• The code may be tampered with during its execution on a host computer.
• The code, when executed on a host computer, can threaten the host computer in vari-
ous ways (e.g., through unauthorized access, transmission of malware).

It is not possible to go into detail here about the possible solution types for defending
against the threats mentioned. With regard to the first two types of threat, trusted com-
puting provides an approach that involves only allowing mobile code to be executed on
systems that are trusted and have been correctly identified.

When protecting the host computer, its access control mechanisms become important.
One possible approach to dealing with mobile code is the sandbox technique, in which an
isolated memory area is defined within which the code can operate freely - outside this
area, access is possible only in a very limited, controlled manner. Another way of protect-
ing the host computer is based on a digital signature of the code by the author, as for
example in the Authenticode method used by Microsoft as protection against harmful
ActiveX controls.

A similar concept are mobile apps, which are not executed as a local application on a
(mobile) end device, but use services provided via a communication network – typically
the Internet – during execution. Frequently, such an app running on an end device acts as
a client in a cloud service, so that the user can access the service regardless of location
and the end device used. An example of this is the Gmail app from Google.

Depending on context, legitimate mobile apps may be threatened by attacks from their
environment, or they may themselves be part of an attack and threaten the environment.
In order to protect (against) such mobile apps, technologies such as access control mecha-
nisms of the operating systems are needed.

73
 Cookies

Cookies are not malware. Rather, they are small pieces of text information that are stored
by a web server on the hard disk of the user. When the same website is visited again, this
cookie is sent to the server as part of the request. Where the cookies are stored on the
user's hard drive depends on the browser used. The cookies can be deleted by the user
individually or altogether.

Cookies are needed for functions such as shopping on the Internet. This is due to the fact
that the pure HTTP protocol acts "stateless", i.e., a web server does not "know" which
pages users have previously accessed, what they have already added to the shopping cart,
etc. So, cookies help the web server to conduct an online business consisting of a
sequence of requests because it can establish a continuous session with the user by
repeatedly reading the cookies. On the other hand, cookies can also be used to display
targeted advertisements to internet users.

Cookies can do no "harm" on their own, but they can be the technical foundation for a
data protection problem, since they can be used – albeit to a limited extent – to observe
user behavior. This is done using third-party cookies, which are cookies that are not set by
the web site itself but by some third party which is for example involved by including an
ad on the original web page. If some other web site then includes an ad from the same
third party, the third-party cookie is sent with the request and the third-party ad provider
can thus track the user across different web sites. The following figure shows such an
interaction.

74
Figure 12: Sequence diagram: Third-party cookies

The following figure shows an example cookie set by IU myCampus. This is a session
cookie used to combine different interactions between user and myCampus into a ses- Session cookies and
sion. persistent cookies
A session cookie is a
cookie that is only stored
for one user session and
deleted automatically
when the browser is
closed. If the cookie is
stored across sessions, it
is called a persistent
cookie, and its duration is
defined by the server set-
ting the cookie.

75
 Figure 13: Cookie properties

5.2 Some Special Features Concerning

Operating Systems
General principles of rights management and access control to computer systems lead to
different approaches of memory and object protection in the various operating systems,
which are then implemented in concrete functions. The basic concepts include, for exam-
ple, access control lists (ACL), which are used, in some variation, in most operating sys-
tems.

76
Windows

Active Directory

An important part of the security subsystem of the Windows operating system is the Active
Directory. This consists of a directory service with a database used for storing information
about the components of a network domain, including passwords and permissions. The
Kerberos protocol is used to establish trust relationships between different network
domains.

Windows: Bitlocker and Encrypting File System (EFS)

Bitlocker and EFS (Encrypting File System) are two complementary components of Win-
dows for securing data by encryption.

The need to encrypt files stored on computers arises from the fact that the access protec-
tion mechanisms of operating systems may be bypassed, for example after a laptop was
stolen, potentially allowing unauthorized persons to access sensitive data. For example, it
may be possible to boot a different operating system on a computer to which an attacker
has physical access, so that the data still on the hard disk is then openly accessible, inde-
pendent of any defined access restrictions.

Such an encrypting file system must of course be designed in such a way that it is secure,
but also easy to use – the user should not need to know cryptography and asymmetric
encryption.

Bitlocker is a drive encryption that relies on a Trusted Platform Module (TPM) in one var- Trusted Platform
iant, but can also only be used together with a USB device. The TPM is used to generate Module (TPM)
A secure cryptoprocessor
and store the cryptographic keys needed. based on the interna-
tional standard ISO/IEC
Microsoft EFS, which is only applicable to NTFS file systems, is a hybrid method in which 11889, used for crypto-
graphic functions within a
variants of the DES algorithm and the AES method are used for encryption (depending on system. Today, most IT
the version of the operating system). An asymmetric key pair is generated by EFS for each systems such as PCs,
servers, tablets or smart-
user. To make this as easy as possible for the user, the key management is as follows: A
phone include a TPM.
symmetric key FEK (File Encryption Key) for encrypting a file is generated by EFS and
stored on disk, encrypted with the user's public key. If multiple users are to be able to
access and decrypt the file, a separate copy of the FEK is stored in encrypted form for each
of these users. The private keys are symmetrically encrypted and stored on the hard disk
using the CryptoAPI belonging to the operating system. The (symmetric) key used is
derived from the password of the respective user, enabling the EFS to obtain the user's
private key immediately when the user logs in, and keeping it available until the user logs
out.

Android and iOS

It is also worth taking a quick look at the way the two most widely used smartphone oper-
ating systems, Android and iOS, handle apps and their permissions.

77
 Android allows users to install any apps they want (i.e. not just those obtained from Goo-
gle Play), but they are initially "not allowed" to do anything. There are far more than 100
different permissions defined, which regulate access to personal data and devices like the
camera and GPS receiver. When installing an app, the user has to allow these accesses. Of
course, there is a risk that the user is quite lax when setting these permission – due to a
lack of awareness of the problem or simply for convenience.

Apple's iOS follows a different access control strategy: Apps can only be installed on a
smartphone if they have been obtained from Apple's AppStore. There, they are subjected
to a review process, in which care is taken to ensure that they only claim the rights they
really need to provide their functionality.

Despite these precautions – for Android as well as iOS – it is of course not impossible that
apps with malicious functions are executed on smartphones. That is why manufacturers
of security software such as virus scanners, etc., also offer mobile variants of their prod-
ucts.

5.3 Web Server Security

Access Control

A web server acts as an HTTP server – a well-known and widely used example is the
Apache HTTP server. In many cases, there is no need for access control for read access by
users, since web servers normally offer information that is intended to be publicly accessi-
ble. However, some content may be offered to a limited group of users only, for example,
the employees of a company. In the case of paid services, access may be restricted to reg-
istered users who have paid a fee or subscription. In all these cases, access control with
authentication of users is necessary.

Most web servers allow access to be restricted based on the IP addresses of the senders of
the requesting data packets, and restrictions to subnets or specific domains are also possi-
ble. In this way, both individual documents and entire directories can be protected. How-
ever, since sender addresses can be forged, a skilled attacker can bypass this protection. A
related problem arises from the frequent use of proxy servers: if the IP address of the
proxy server is accepted for access, this also applies to all clients that use this proxy server.
When using host or domain names for restricting accesses, there is the additional problem
DNS spoofing that a false IP address may hide behind a trusted host name as a result of DNS spoofing.
An attack form where an
attacker manages to store
a corrupted IP address on HTTP also allows access to web pages dependent on the authentication of the user with
a Domain Name Service name and password. With simple HTTP Basic Authentication, the server sends a WWW
(DNS) server. As a result, Authenticate Response header to the client after the first access attempt, whereupon the
clients that try to access
the relevant domain and browser prompts the user for a username and password.
ask the DNS server for the
appropriate IP address
get an incorrect answer
and will access the
domain defined by the
attacker.

78
With this data, the request is sent again to the server, which checks it and, if the identity is
confirmed, transmits the response. By default, these data are transferred without encryp-
tion, so it is important to combine the use of basic authentication with HTTPS. To check
the authentication data, the web server must have stored the allowed users with their
passwords. This information is stored in a file .htpasswd with the following structure:

myName:myPasswd
myName:$apr1$r31.....$HqJZimcKQFAMYayBlzkrA/
myName:$2y$05$c4WoMPo3SXsafkva.HHa6uXQZWr7oboPiC2bT/r7q1BB8I2s0BRqC

The example in the first row defines the user myName with the password myPasswd. Of
course, this contradicts the general rule that a password should not be stored in plain text.
The second row describes a better solution: as the identifier “apr1” shows, an iterated
MD5 hash of the password is used, with the salt “r31.....”. The MD5 hash function is still
widely used, even though it is no longer safe and can be broken by brute-force attacks on
standard PCs. A secure approach to store the password of user myName is shown in the
third row where the password is hashed using the bcrypt hashing algorithm, as can be
seen from the identifier “2y” (The Apache Software Foundation, 2022).

Since the HTTP protocol is stateless, which implies that each request is handled sepa-
rately, the name and password must always be sent along with further requests to the
same server. Therefore, browsers are programmed in such a way that this data is also
always transmitted automatically without user intervention.

Since version 1.1 of HTTP, web servers have the possibility to use an improved method
called HTTP Digest Authentication. Here the server sends a mark (nonce) with the request Nonce
for authentication, which then acts as a challenge for a challenge-response protocol. The A (usually random) num-
ber that is used only once
client uses its username, password and the nonce with the MD5 hash function to form the in cryptographic proto-
appropriate response that the server expects for successful authentication. Apart from the cols to prevent replay
insecurity of the MD5 hash function, the problem with this process is this: Since the server attacks.

does not remember (due to statelessness) an issued nonce, it must be derivable from the
request data and the data residing on the server – but this opens the door to potential
replay attacks. The resulting risk is admittedly quite small if even the full URL is included
in the nonce calculation. Since the marks are selected under the sole responsibility of the
respective web server, different variants of this process are in use.

In conclusion, both authentication procedures only offer a low degree of security so that
they should only be in use cases with low security requirements.

Common Gateway Interface (CGI)

Another important security aspect of web servers concerns Common Gateway Interface
(CGI) scripts that cause programs to run on the web server, possibly causing damage. CGI
is an interface definition that can be used to integrate programs written in different pro-
gramming languages with a web server. CGI is used on web servers to enable URLs to
respond to a user request with a dynamic response instead of a static web page. For exam-
ple, it can be used to make the response dependent on the information the user provides
in a web form.

79
 CGI is not a full programming language, but rather a means of accessing an executable
program from a URL. Even though such a program can in principle be written in any lan-
guage, mainly PHP, but Perl and Java are the next most widely used languages for this pur-
pose. In order to pass information to programs, CGI must be able to send arguments and
receive values, which is done via URLs or web forms. It should be clear that CGI scripts -
like the web server itself - must be programmed with great care to avoid providing attack
surfaces for unauthorized attackers. The two main problem areas are as follows: CGI
scripts can expose information about the server that allows unauthorized people to hijack
the system. CGI scripts that process user input can potentially be tricked by the user into
executing further commands, for example by triggering a buffer overflow, which will be
explained next.

Security of Web Applications

A very common type of vulnerability resulting from implementation errors in both operat-
ing systems and application services concerns the buffer overflows. Buffer overflow
attacks rely on data being written into some storage area without checking whether the
data fits into that storage at all. This may cause the storage to "overflow", overwriting
other memory areas that follow the one intended for storing the data. By careful selection
of the data entered into a user input field, an attacker may in such a case be able to coerce
the system into executing code provided by the attacker.

A similar problem was present in the Heartbleed bug: in OpenSSL, a commonly used
implementation of SSL/TLS for web servers, a fatal bug was discovered in 2014 (and then,
of course, soon corrected) - the implementation error was that in a user input, the permis-
sibility of a length input for data that the server should send back was not checked – this
led to a "buffer overread". In unfavorable constellations, this could lead to unauthorized
reading of a secret key.

Common attacks on web servers are:

• Denial of Service (DoS) attack: deliberately causing an overload by sending an excessive

number of requests.
• SQL injection: The attacker sends short text-based attacks that abuse the syntax of the
target interpreter, for example using special characters in a text input field, resulting in
unauthorized access to or manipulation of an SQL database.
• Cross-site scripting (XSS): The attacker sends text-based attack scripts that exploit
browser properties for malicious actions on other clients.

Avoiding such problems through careful software development has today become an
important discipline in its own right under the heading of "secure software" or "secure
software development".

Server Logs and Privacy

Another aspect concerns data protection. Most web servers log every access and thus
record a variety of information about the users visiting the site, such as the IP address
used, the exact time of access, the requested URL, etc. Some browsers also send the previ-

80
ous URL that the user accessed to the server, as well as their email address. A web server
can not only store all this data, but in turn make it available to CGI scripts, which then ini-
tiate some action (for example, send an email to the user). It is obvious that this raises the
issue of data protection or privacy. Generally, it is assumed that a correctly administered
web server stores the log files for statistical purposes only. If the web server does not need
to identify individual users but wants to map different activities of the same user during
one session for statistical evaluation, this is usually done by anonymizing the IP address,
i.e. deleting part of it, typically the last 8 or 16 bits. Particularly in the context of e-com-
merce, however, there is a conflict with the interests of the operator of a web server in
being able to determine the identity of a customer or to prevent a fraudulent order under
a false name.

Proxy servers must also be considered in this context: A proxy server that provides access
to Web services outside the corporate firewall will typically log every outside access in full,
so a poorly configured proxy server poses a serious threat to privacy.

SUMMARY
Individual computers can be exposed to threats in different ways. Such
threats may arise from inadequate access protection, from malware or
from programming errors (bugs). In comparison, cookies in many cases
are legitimate tools for overcoming the limitations of the HTTP protocol,
and do not pose a threat to the computer, but may also be used as a tool
for tracking user behavior.

To protect against these threats, numerous different types of protection

mechanisms for computers and data are provided in common operating
systems. For example, the Windows operating systems have integrated
sophisticated technology for data encryption in the form of Bitlocker
and Encrypting File System.

A closely related topic is the security of web servers. CGI scripts play a
special role here. Typical programming errors or negligence, such as the
possibility of buffer overflow, also occur frequently with web servers.
Particularly security problems with web server software have put the
topic of "secure software" more firmly on the agenda within computer
science.

81
 UNIT 6
SECURITY IN COMMUNICATION NETWORKS

STUDY GOALS

On completion of this unit, you will be able to ...

– name and explain the most serious threats in communication networks, especially on
the Internet.
– discuss the general principles used for defense against attacks in communication net-
works.
– demonstrate most important standards for communication security on the Internet.
– analyze how identities are handled on the Internet and what role anonymity plays.
– illustrate the specific problems and solutions that arise in mobile and wireless commu-
nications.
 6. SECURITY IN COMMUNICATION
NETWORKS

Introduction
This unit discusses communication networks in general, mostly focusing on the Internet,
since other networks, such as mobile networks, are increasingly acting as access points to
the Internet today. Some aspects can only be briefly touched upon here; the multi-layered
and extensive topic of security in communication networks could easily fill an entire
course.

The reader is expected to know the basic concepts of Internet technology, in particular
TCP/IP, data packets, and IP addresses.

6.1 Security Problems and Defense

Concepts
Regarding security in communication networks, a distinction is usually made between two
aspects: On the one hand, segmentation of networked systems to prevent undesired data
traffic between certain networks or network parts, and on the other hand, mechanisms for
securing communication protocols and protecting application services. This section deals
with both aspects.

Firewalls

A firewall forms a "protective wall" between a computer system or a local network and the
Internet, filtering data traffic between inside and outside the wall. This filtering is the cen-
tral task of a firewall - a firewall is not based on cryptography.

The main purpose of a firewall system is to protect against attacks from the Internet. A
firewall therefore usually is installed at an interconnection between two (or more) net-
works in order to control traffic at this interconnection. All data exchanged between these
networks must pass through the firewall system and is either allowed through or rejected.
For this purpose, the firewall system analyzes the communication data, controls the com-
munication relationships and communication partners, regulates the communication
according to a defined security policy, logs events relevant to security and alerts the secur-
ity administrator in case of severe violations. A typical constellation is that for a company
network connected to the Internet, all traffic must pass through the firewall system. If a PC
is protected by a firewall, this is referred to as a personal firewall.

84
Figure 14: Basic setup of a firewall system

The firewall checks each data packet to see whether it is allowed or forbidden and sends
the packet on or rejects it accordingly. These permissions and prohibitions are defined as
rules recorded in a list that is processed from top to bottom.

Just as important as the use of a firewall is its correct configuration, i.e. the definition of
the rules. In the case of a firewall for private users, the rules can generally be configured
automatically. However, by doing so, you give up the ability to determine for yourself who
is allowed to access your computer system and what data is allowed to leave it. To be on
the safe side, one should always follow the rule that everything that is not explicitly
allowed is forbidden.

A firewall should have at least the following functionality:

85
 • Packet filtering: The headers of all packets passing through the firewall are checked.
The firewall decides for each packet whether to allow or block it.
• Network Address Translation (NAT): The outside world sees only one or a limited num-
ber of IP addresses, while the internal network can use any private address space. Inter-
nal and externally visible IP addresses and ports are automatically translated back and
forth by the NAT functionality. The main advantages of NAT are that IP addresses can be
reused in different networks (which is particularly important in IPv4, which only sup-
ports a very limited number of IP addresses), and that internal IP addresses can be hid-
den from the outside world.
• Application proxy: The firewall can check other data contained in the packets in addi-
tion to the header data. To do this, it must understand the specific application protocol.
• Monitoring and logging: the firewall logs all important activities to allow later analysis
of security breaches. While this can be very useful from a security point of view, it can
lead to data protection issues since the activities logged are often human activities, and
the log data are often personal data.

Many firewalls support the following additional features:

• Data caching: Data can be cached - this means that it does not have to be requested
from the websites every time.
• Intrusion detection: The firewall detects "intrusion attempts" and can cause an alarm.
• Load balancing: Incoming and outgoing data traffic can be distributed across multiple
firewalls if required.

In practice, different types of firewall systems are used. A firewall can be based on hard-
ware or software. Hardware firewalls (consisting of hardware and software, of course) per-
form their functions as soon as they are connected. Software firewalls are programs that
have to be installed on a computer system, and the computer system is usually used for
normal application programs in parallel to its function as a firewall.

The numerous different types of firewall systems can, for example, be distinguished based
on the communication layer of the TCP/IP model on which they operate. The following
basic components can be distinguished:

• Packet filtering
• Stateful inspection
• Application gateway
• Adaptive proxy

One speaks of a packet filter or packet-filtering router when selective packet filtering takes
place at the network and transport layers. A packet filter looks at the packets and verifies
that the data in the corresponding headers conform to the defined rules.

Different checks can be performed by a packet filter at the different communication lay-
ers: At the network layer, depending on the protocol, the destination and source address,
the higher-level protocol used, option fields and flags, etc., are checked. On the transport
layer a check of the port numbers takes place, possibly (for TCP) also a check of the direc-

86
tion of the connection. In addition, it is also possible to check whether access via the
packet filter takes place during a defined period (e.g. only Monday to Friday, between 7
a.m. and 5 p.m.).

An extension of packet filters is stateful packet filters. Here, packets are also interpreted at
higher communication layers, i.e., status information for current connections is evaluated
and recorded at the various layers. Such information can relate, for example, to connec-
tion setup, transfer status or connection termination. However, application gateways and
proxies, which will be discussed next, offer a better and more secure concept for analyzing
application data.

An application filter (application gateway) is a software system that runs on the applica-
tion layer. It monitors the connections of a service and can also block individual com-
mands. Users who want to communicate via the application gateway must first authenti-
cate themselves. To do this, they establish a connection to the application gateway. After
that, the application gateway works transparently, so that it looks to the users as if they
work directly on the target computer system rather than via a gateway. An application
gateway usually works with two network ports (and is then also called a dual-homed gate-
way), so that all relevant traffic has to pass via the gateway and the gateway has complete
control over the traffic.

The application gateway receives the packets on the corresponding ports. If, for example,
only one service is to be allowed via a corresponding port, the application gateway must
ensure that (only) the corresponding packets are transmitted from one side of the network
to the other (and vice versa). Software that performs packet transmission for a specific
service (FTP, http, telnet, etc.) in the application gateway is called a proxy. The term proxy
is used because from the user's point of view it looks like communicating directly with the
server process of the service on the target computer system. Each proxy on the Applica-
tion Gateway can provide additional security services for the service it is responsible for.
Nevertheless, proxies are quite small and manageable software modules, so misbehavior
due to implementation errors is quite rare. The specifics of different proxies (SMTP proxy,
FTP proxy, HTTP proxy) are not discussed here.

In general, an application gateway should always be used when there is a need for protec-
tive measures to be made available for the applications. In particular, this includes logging
options at the application level. The disadvantage of an application gateway is low flexibil-
ity, since a separate proxy must be provided for each service or application. Also, the costs
are higher than those for a packet filter. Under the name Adaptive Proxies, attempts are
being made to combine the advantages of packet filters with those of application gate-
ways. The approach is that the firewall system works like an application gateway in the
first phase (connection setup) and like a packet filter later. Assuming (quite correctly) that
most attacks affect the connection setup, this approach achieves satisfactory security.

Finally, the concept of a demilitarized zone (DMZ) must be mentioned. This is an addi-
tional network segment used to isolate the internal network from external ones. Typically,
an application filter is located in this zone, and WWW or other servers may also be inclu-
ded; the DMZ is preceded and followed by one packet filter each.

87
 Figure 15: Structure of a Demilitarized Zone (DMZ)

As can be seen, there are numerous ways to build a firewall system. Accordingly, the man-
ufacturers offer a variety of systems on the market which differ greatly in terms of their
performance (i.e., the possible throughput) and price.

In addition to the firewall systems required for corporate networks, personal firewalls or
PC firewalls are also increasingly in use today, which are of particular interest to telework-
ers, but also to private users. This involves the protection of individual PCs, which is
becoming more and more relevant in view of the increase in teleworking as well as private
Internet use. The personal firewall solutions on offer vary widely. The more classic firewall
functions, which control incoming and outgoing traffic according to predefined rules, are
usually integrated. The newer Windows operating systems are already equipped with a
firewall solution. Alternatively, there are a number of software solutions that have to be
installed additionally for the various operating systems, the basic versions of which are
often offered free of charge for private use. Some of the PC firewalls on offer also include
antivirus protection. Some products supplement this functionality with a proactive sand-
box principle. In simple terms, this causes unknown applications to run in a kind of "quar-
antine", preventing unwanted actions from occurring on the PC. Other products focus on
an intrusion detection concept, i.e. network traffic is monitored for known hacker attack
patterns. Cookie management can be integrated, as well as content control, where emails
are monitored for certain keywords, so that no Trojan horse can send passwords, for
example.

Many DSL (Digital Subscriber Line) routers also work as firewalls. A DSL router enables
multiple, locally networked computer systems to be connected to the Internet via DSL.
This means that unrestricted access to the Internet is possible from the local network, but
access from the Internet to the local network is not permitted. The DSL router takes care of
blocking the ports and includes NAT support.

Protocol Layers

First of all, the OSI model (Open Systems Interconnection Model) must be remembered,
which is a reference model for network protocols that represents the communication pro-
tocols in a layered structure. This structuring achieves a reduction in complexity and
makes the practical implementation of the interacting protocols possible in the first place.

88
The basic principle of structuring in layers is that in a communication relationship corre-
sponding layers of the systems involved communicate with each other via a suitable pro-
tocol. Within a system communicating with another system, each layer has the task of
receiving messages from the next higher layer, processing them and forwarding them
using the services of the layer below. For messages, this has the consequence that each
layer (since it has its own needs) adds control information in the form of a header; for this
reason, the message finally transmitted by the physical layer consists of the original mes-
sage coming from the application layer plus a set of headers - this is called the encapsula-
tion of data.

The OSI model is an ISO standard and consists of seven layers, numbered from bottom to
top. Parallel to this, the TCP/IP layer model has developed, which is based on the same
idea, but only contains four layers. The following explanations focus on the TCP/IP model
since this model is nowadays commonly used to connect to the Internet. The technical
standards issued for Internet technology are referred to as Requests for Comments (RFC).

In the following figure, both models are shown side by side. It can also be seen which of
the OSI layers are combined in each case to form a layer in the TCP/IP model.

Table 2: Reference Models for Network Protocols

OSI Reference Model TCP/IP Model

7 Application Layer 4. Application Layer

6 Presentation Layer

5 Session Layer

4 Transport Layer 3. Transport Layer (TCP Layer)

3 Network Layer 2. Internet / Network Layer (IP Layer)

2 Data Link Layer 1. Link Layer

1 Physical Layer

The figure "Encapsulation of data in TCP/IP layers" shows the encapsulation of data in the
TCP/IP model, including of the protocols located on the respective layers.

On the subject of firewalls, it should be added that according to the above classification of
types of firewalls, packet filters are assigned to OSI layer 3, proxies to layer 4 and applica-
tion filters to layer 7.

89
 Figure 16: Encapsulation of data in TLC/IP communication

Security problems of Internet protocols

At this point it is assumed that the reader is familiar with the basic properties of the Inter-
net protocols IP and TCP, furthermore the routing principles for IP, the role and structure
of IP addresses as well as the concept of virtual connection for TCP.

IP and TCP do not originally provide any security mechanisms. When these protocols were
designed and tested in the 1970s in the USA, first in the military and then in a research
environment, their security was not yet an issue – unlike today, when these technologies
have become a basis of day-to-day communication in business and private life. At this
point, it must be pointed out that security weaknesses in IT as a whole (not just in commu-
nications networks) can always result from various causes:

• inadequate consideration of security aspects in the design of the overall system,

• logical errors or gaps in the protocols,
• faulty implementation

The following have turned out the be the most important vulnerabilities of IT systems:

• Lack of authenticity: the IP address of the sender of a data packet is not verified, ena-
bling several types of IP spoofing attacks. Also, different types of denial-of-service
attacks can exploit this.

90
• Lack of confidentiality, integrity and non-deniability: by default, neither the user data
nor the header data of an IP packet are encrypted before transmission; everything is
transmitted openly. This means that there is no confidentiality, integrity or non-denia-
bility whatsoever. Additionally, communication profiles can be created, i.e., there is no
anonymity either. Various routing attacks are also possible, since the IP routing proto-
cols allow preferred routes to be entered in the data packets.

The IP layer includes the protocols ICMP (Internet Control Message Protocol) and ARP
(Address Resolution Protocol), which also have weaknesses. (ICMP is sometimes attrib-
uted to the TCP layer - see the preceding figure).

ICMP is responsible for transmitting error and status messages on the network. For exam-
ple, a status message may concern the unavailability of a router to forward messages. Sev-
eral ICMP message types can be misused for denial-of-service attacks, and targeted redi-
rection of packets is also possible (redirect attack).

The ARP protocol is responsible for mapping IP addresses to physical MAC addresses. (The
abbreviation MAC in this context stands for Media Access Control, not to be confused with
Message Authentication Codes relevant elsewhere!). Each computer maintains an ARP
address table in its cache for this purpose. An ARP cache poisoning attack causes a com-
puter to store incorrect information about the assignment of an IP address to a MAC
address in its cache.

The connectionless UDP and connection-oriented TCP protocols are considered as part of
the transport layer. Attackers can easily smuggle in UDP packets or make them disappear;
communication is based only on IP addresses, which are known to be easy to forge. How-
ever, when UDP is used - for example, for Internet telephony - this usually does not have
any serious consequences.

There are no functionalities in TCP that cure the above security weaknesses of IP. The
main function of TCP is merely to make the data traffic belonging to a communication
relationship more reliable by establishing virtual connections and introducing sequence
numbers. Specific forms of attack that result from this are, for example, the possibility of a
"hostile takeover" of a client-server connection (referred to as session hijacking) and the
possibility of deliberate desynchronization of an existing connection.

Security on the Internet layers

Most security mechanisms that have become established for Internet communication can
be assigned to one of the four layers of the TCP/IP model. It is sometimes not clear from
the outset which layer is "responsible" for implementing a security function - several solu-
tions are often possible. However, the following should be clear: Locating security proto-
cols on a layer means that the software components implementing that layer must be
modified or extended. This is an important consideration since today's computer operat-
ing systems are equipped with TCP/IP components by default. The problem of backward
compatibility remains especially important. On the other hand, the location of security
functions on a particular layer always has the advantage that the software of the layers
above does not have to be changed.

91
 For the link layer, which is responsible for transporting packets on the physical media, the
point-to-point protocol (PPP) has become the standard used for dial-up connections,
which are typically used by users to access their Internet providers. This protocol only pro-
vides authentication as a security feature, which can be performed with a password or a
challenge-response method. Encryption or integrity assurance are not supported by PPP.

For security at the IP layer, a collection of security protocols has been established as an IP
extension under the name IPSec; the current standardization was carried out with RFC
4301. IPSec is described in more detail below.

The same applies to SSL/TLS, which has established itself as an Internet security standard
for the TCP layer and is used by the most important application protocols. Also located on
the TCP layer is SSH (Secure Shell), which can be used to establish secure terminal con-
nections and for secure file transfer. However, SSH will not be discussed any further here.

With regard to the security mechanisms located on the application layer, there are once
again two basic options:

• Extension of the existing application protocols to include security functions (example:

Secure FTP as an extension of FTP)
• Setting up security protocols on top of the unchanged standard applications (example:
HBCI via HTTP).

The following figure summarizes how the security mechanisms mentioned fit into the
layer model. (The protocols in focus in each case are shown in bold).

Figure 17: Security mechanisms in the layer model

92
Security problems in application layer services

Because of the variety of protocols and services in the application layer, the protocols
located here will be looked at separately. In the following, the focus will be on network
services that operate "in the background", often without any conscious action on the part
of the user, but are necessary so that the user services function properly.

Domain Name System (DNS)

Of central importance for the functioning of the Internet and WWW is the Domain Name
System (DNS). Its task is to map symbolic DNS names to IP addresses or, conversely, to
specify the associated DNS name for an IP address. The need for such a service is obvious:
when users enter a URL such as http://www.iu.org in their browser, a TCP connection
is to be established from this browser to the web server for processing HTTP requests. To
establish a TCP connection, however, the user's browser must know the IP address of the
web server, which is provided by the DNS server.

The DNS names with the associated IP addresses are managed decentrally on different
DNS servers and can be queried there. The different DNS servers are arranged hierarchi-
cally. If a DNS server cannot answer a query, it "asks" another server and stores the
answer in its own cache so that next time, it can answer the same query directly. This mes-
sage exchange is based on the unprotected UDP protocol, so attacks are easily conceivable
here. DNS spoofing is when an attacker succeeds in placing a false mapping between IP
address and domain name in a DNS server. If a DNS server can be made to enter a false
name in its cache, this is called DNS cache poisoning.

Since the weaknesses of DNS are well known, work on the DNSSEC extension (Domain
Name System Security Extension) has been going on for several years, and it has now been
implemented for most top-level domains. The security functions of DNSSEC ensure the
authenticity and integrity of DNS records, using asymmetric cryptography and crypto-
graphic hash functions for this purpose. However, denial-of-service attacks on DNS servers
remain possible despite DNSSEC.

Network File System NFS

The Network File System (NFS) is a protocol that was originally developed by Sun Micro-
systems and allows files to be accessed over a network. Access takes place from the user's
client computer - unlike the File Transfer Protocol (FTP), where the sending side needs to
be active. NFS is strongly influenced by the UNIX world, but there are equivalents in other
operating systems and interconnections between the different "worlds".

In IP networks, NFS worked in versions 2 and 3 on the basis of UDP. However with version
4 this has changed to TCP. In terms of security, version 4 is much better equipped than the
previous versions. For example, RSA encryption is provided and Kerberos has also become
part of the overall protocol.

93
 6.2 Internet Standards for
Communication Security
This section describes the main security standards used on the Internet today. We will
start with the SSL/TLS protocols, which are the most widely used Internet security proto-
cols.

SSL/TLS

SSL (Secure Socket Layer) is a protocol that builds on the TCP/IP protocols and forms a
basis for higher protocols of the application layer, such as HTTP (which thus is turned into
HTTPS). The SSL protocol lies above the TCP/IP layer and essentially consists of the two
sub-protocols: SSL handshake protocol and SSL record protocol. Application protocols
such as HTTP can access the transport layer directly, but access is also possible using the
Secure Socket Layer as an intermediate layer, turning the protocol into HTTPS.

Figure 18: SSL in the network layer model

SSL was originally developed by the company Netscape and was included in the Netscape
Navigator browser, one of the first browsers available. Since about 1994, SSL has steadily
become the predominant protocol for security at the TCP layer, especially for securing
HTTP traffic. Today SSL is supported by all modern browsers, although it is now being fur-
ther developed as an industry standard under the name TLS (Transport Layer Security) –
for this reason the term SSL/TLS is often used. The current version 1.3 of TLS is described
as an Internet standard in RFC 8446.

TLS helps to secure a TCP connection through the following properties:

• The connection is confidential. In the handshake protocol (see below), secret keys are
agreed upon, which are then used for symmetric encryption.
• The communication partners can authenticate themselves using asymmetric methods.

94
• The message transport includes integrity protection through the use of a MAC (Message
Authentication Code).

The following figure shows an example of how transmitted application information ("My
account number") is cryptographically protected in TLS. TLS protects header and user
data of the application, but the control data of the deeper layers are transmitted unpro-
tected.

Figure 19: Message protection using TLS

TLS implements a hybrid combination of symmetric and asymmetric encryption. Many of

the known symmetric and asymmetric cryptographic methods and hash functions can be
used – specifically DES, 3DES, AES, RSA, Diffie-Hellman, MD5, SHA-1 and others; their use
is agreed upon by the communication partners when setting up a connection. In order to
communicate using TLS, both client and server must know that the other is using TLS. One
way to do this is to use reserved port numbers – for example, port 443 is designated for
https. Another way is for each application to use the standard port (for example port 80 for
http), and the modified application protocol negotiates the security options. Browsers
usually indicate the use of TLS by a small lock. Also, the URL starts with https instead of
http.

A TLS transmission always begins with an exchange of messages called a TLS handshake.
Using https communication as an example, it works as follows: the user’s browser first
fetches the server’s public key from the server. (The server's private key is kept confiden-
tial, of course). The browser generates another key called a session key, which is encryp-
ted using the server's public key and then transmitted to the server. There it can only be

95
 decrypted with the help of the server's private key. Now the sender and receiver have a
common key that is not known to any third party and they can transmit data using sym-
metric encryption. (This representation is somewhat simplified; in reality, the keys used
are only derived locally from a shared secret).

The actual transmission of the encrypted data is done using the TLS record protocol. The
data to be transmitted is divided into packets of suitable size, and compression is option-
ally applied. Then the packet is encrypted and signed with the MAC (Message Authentica-
tion Code) and eventually transmitted in the usual way using TCP/IP. On the receiving end,
the original data is obtained again. While the encryption protects against passive attacks,
the MAC ensures that the data cannot be manipulated unnoticed.

How can you guarantee on the web that the provider of the server you contact, for exam-
ple an online store, is indeed the provider you expect?

This is done by using certificates that ensure the authenticity of the provider. Such a certif-
icate is a kind of "authentication" for the server's public key. For TLS, a certificate is cre-
ated by one of the various certificate authorities, e.g. Thawte Consulting or Verisign. These
bodies verify the identity of the provider and its server and issue a certificate to confirm it.
Such a certificate contains, among others, the following information:

• Certification authority,
• validity period of the certificate,
• name of the applicant for whom the certificate is issued,
• public key,
• encryption algorithm used.

In most cases, it is sufficient to use a certificate to guarantee the authenticity of the server.
In principle, however, the same technique can also be used to ensure the authenticity of
the client. This is important, for example, if a bank wants to send confidential information
to a client and must therefore ensure that the recipient is really the desired customer.

Browser manufacturers have implemented TLS in such a way that the user does not usu-
ally have to worry about certificates: clicking on a https link connects to a TLS-protected
page. This works because a list of root certificates is already included in every browser. If
the browser establishes a TLS connection to a website whose certificate can be verified
using one of these root certificates, the website is considered trustworthy. If the latter
does not work because the server's SSL certificate cannot be verified with one of these
root certificates, the user receives an SSL warning message. However, the "normal" Inter-
net user can do nothing about this apart from possibly informing the provider of the web
site.

There are several software implementations of the TLS protocol available, in particular the
widely used OpenSSL, which is installed with the well-known Apache web server, and
GnuTLS.

96
SSL/TLS Security

As always, the question of security has two sub-aspects in the case of SSL/TLS:

• How secure, on a theoretical level, are the protocols grouped under the name SSL/TLS?
• How well are the protocols implemented in practice, i.e., how secure are concrete
implementations?

With regard to the first question, it should first be noted that although SSL/TLS establishes
encrypted communication between two authenticated endpoints, it does not ensure non-
deniability, since the data transmitted from the client to the server is usually not signed –
in other words, the communication is not symmetrical in this respect. A second issue: in
more complex scenarios with multiple servers, SSL/TLS is not easily applicable. Finally,
there are also problems with the interaction of SSL/TLS protocols with application filter
firewalls. This cannot be discussed further here.

On the implementation level, there was a large glitch detected, the Heartbleed bug in
OpenSSL that was discovered in 2014. This Heartbleed incident can be seen as an object
lesson: The best cryptography is of no use if no attention is paid to the practical imple-
mentation!

IPSec and VPN

IPSec is a security standard defined by the IETF (Internet Engineering Task Force) and
defines a security architecture for the IP protocols IPv4 and IPv6, and has been included in
IPv6. The general approach of IPSec is to secure data at the IP layer. For the encryption of
an IP packet, this means that the data originating from higher layers (i.e. from the applica-
tion and TCP layers) is encrypted. Only the resulting modified IP data packet is equipped
with the IP header. Applications such as email etc. do not even see this encryption service
from IPSec, nor do the routers involved along the way. This is illustrated in the following
figure - note the difference to the previous figure "Message protection using TLS".

97
 Figure 20: Message protection using IPSec

Computer systems that use this type of end-to-end encryption obviously need suitable
IPSec software.

The following figure shows a typical scenario in which LANs at different locations use
IPSec for data traffic over the public Internet. IPSec is handled in routers or firewalls that
connect the respective LAN to the outside world. The workstations and servers within the
LANs are not affected by this encryption and authentication of all traffic. As shown in the
figure, a single computer system can also participate in this secured communication, pro-
vided it has an implementation of the IPSec protocols.

98
Figure 21: IPSec Application Scenario

In general, IPSec is referred to as transport mode when only the upper layers (i.e., from
TCP) are protected with it. However, IPSec can be used in a second mode, the so-called
tunnel mode. In this case, not only the data of the upper layers, but the entire IP packet is
protected. In order for routers on the path to be able to handle the packet correctly, the
packet must be equipped with an additional IP header in this case. The next figure shows
the two variants of modifying data packets using IPSec - in a): transport mode, or b): tun-
nel mode; with "IPSec" additional data is inserted here, which will be discussed in more
detail below.

99
 Figure 22: IPSec Packages

The IPSec protocol that provides encryption is called ESP (Encapsulating Security Pay-
load). ESP also provides data integrity, authentication of the data source of the IP packets
and protection against replay attacks. The AH protocol (for: Authentication Header) pro-
vides the same capabilities as ESP except for encryption.

IPSec allows numerous types of virtual private networks (VPNs) to be set up, and the two
modes (transport and tunnel mode) can be combined in different ways.

The simplest constellation with use of the transport mode is shown in the following figure:
end-to-end protection of IP packets takes place between the participating computer sys-
tems, each of which belongs to a LAN, with the Internet interposed as a wide-area net-
work.

100
Figure 23: Security of IPSec in transport mode

The basic constellation of IPSec use for a VPN can be seen in the next figure. With tunnel
mode, the original IP packets are packaged again so that a tunnel through the Internet is
created (between the routers involved), whereby a private subnet of the Internet exists
from the point of view of the feeder networks involved - a virtual private network, in other
words.

101
 Figure 24: Security of IPSec in tunnel mode

The numerous ways in which IPSec can be used result from the different options for com-
bining transport mode and tunnel mode depending on the network constellation. In a
site-to-site VPN as in the previous figure, for example, it is possible to use IPSec in trans-
port mode on both sides of the tunnel within the local networks.

Today, an important application of VPNs is the anonymous access to a service or website,

or the secure access to a service or website via an insecure network such as a public wire-
less LAN. In their marketing material, suppliers in this case often state that they offer a
VPN even though this strictly speaking is a VPN-based service. This service is usually provi-
ded by routing traffic from the user to the VPN-based service via VPN, and only from there
to the desired service (and back). The VPN-based service can then hide the IP address of
the user from the website or service. Of course, this assumes that the provider of the VPN-
based service must be trustworthy, since technically this service is able to monitor any
network traffic of the user.

102
IPSec Security

The question of how secure are the IPSec protocols and their existing implementations
represents a comprehensive topic to which one could devote a separate course. Several
types of attacks are known but too complex to be discussed here. It should only be men-
tioned that IPSec contributes to assuring authenticity, confidentiality and integrity, but
not to non-repudiation, since no functionality similar to a digital signature is included.

A major practical problem is due to the fact that the correct configuration of an IPSec sys-
tem (security services offered and their characteristics) is a highly demanding task.

6.3 Identity and Anonymity

Today, ID cards or authorization certificates such as driver's licenses usually come in the
form of smart cards. With the help of such plastic cards, it is possible to identify people if
these cards are linked to a person via a photo, fingerprint or other biometric feature. The
present section deals with the question of how digital identities are represented in the
"online world," especially on the Internet. Again, this is a broad field, of which only a few
aspects are considered here – it already begins with the ID card just mentioned, which
provides (optionally) an eID function with which one can authenticate oneself as a person
on the Internet.

Accounts with username and password

The simplest – and not particularly secure – form of online identity is implemented
through a typical online account based on username and password. Access is regulated in
this way for numerous web offerings: after a one-time registration with definition of user-
name and password, the offer can be accessed again and again with these data. If the
service is also used for online shopping, account data, etc. can often be entered during
registration to facilitate future shopping.

Concepts such as a Google account represent an extended offer. Here, a single registration
process leads to personalized use of various Google services such as Gmail, Calendar, etc.
(In a strict sense, "personalized" is not correct, since the user can also appear pseudony-
mized). In addition, the setting of cookies ensures that the login remains even if the corre-
sponding device (PC, tablet, smartphone) has been switched off in between. These
options, which are initially convenient for the user, can of course collect and store exten-
sive data about the user and his or her online behavior, causing major privacy concerns.

Since authentication using a password as the only factor to check the user identity has
become rather insecure, many systems today use an additional second factor. Such a sec-
ond factor should be selected from a different group of factors, keeping in mind the three
standard groups of authentication by knowledge, by possession, and by biometric proper-
ties.

103
 Anonymity

When using web offers, it is sometimes useful or even necessary to correctly identify the
user. This applies in particular to shop systems through which a purchase (including pay-
ment) is to be made. In general, however, it should be possible to remain anonymous as a
user of communication networks. For example, it is nobody's business which websites a
user visits. In authoritarian states, unwelcome surfing behavior can even result in repres-
sion. In many other countries, a right to anonymity on the Internet can also be derived
from the right to freedom of expression.

There are different types of anonymity in communication networks. The sender of a mes-
sage is said to be anonymous if the anonymity of the sender of the message is guaranteed
both towards the recipient and towards any third party. Accordingly, anonymity of the
recipient is given if the sender of a message does not know the identity of the recipient.
Both together are summarized under the term mutual anonymity. We speak of unobserva-
bility when not even the existence of a communication relationship between two partners
is revealed to third parties. Finally, in the context of client-server architectures, a distinc-
tion is made between client and server anonymity.

What data is transmitted when surfing the web? When a URL is entered in the browser, an
HTTP(S) request for a specific piece of information (e.g., for an HTML page) is sent to a
Web server. At the same time, without the user having consciously initiated it, a number of
administrative data can be transferred, such as the email address (as entered when setting
up the browser), the version of the operating system, etc. The server that receives this
request responds with an HTTP(S) response, sending the requested information and other
administrative data to the client.

One way to provide client anonymity in this scenario is to use a proxy. A proxy receives the
HTTP request from a client and removes all information from it that allows conclusions to
be drawn about the client before the request is forwarded to the web server. The response
from the web server is sent back to the client by the proxy. This type of proxy is called an
anonymizer, and there are a number of such anonymizers available on the web, some of
which can be used free of charge.

A different approach to anonymization is used in the Tor project which is a distributed

anonymization network with dynamic route selection. Here, TCP connections are routed
via special Tor nodes and changed every ten minutes. There are thousands of such Tor
nodes – each participant in the Tor network can make his own computer system available
as such a node (provided his Internet connection has sufficient bandwidth). Tracking con-
nections is not impossible in this network, but the corresponding entity would have to be
able to monitor a very large part of the entire Internet.

The "dark side" of Tor is that the darknet, as a part of the Internet where illegal business is
conducted anonymously, is based on the Tor network.

104
Mixes Darknet
is a network layered on
top of some other net-
Another important anonymization technique is the mix concept, which uses public-key work, but which is only
cryptography and a back-to-back connection of several mix servers. accessible from the other
network using specific
software, configuration
The basic idea of how mixes work is as follows: first, a public-key infrastructure must be in etc. The term is mainly
place, and all potential communication partners as well as the mix servers have asymmet- used for certain parts of
the internet which are
ric key pairs. If participant A wants to send a message to participant B, they first encrypt it only accessible via Tor,
with B's public key and sends the result to a mix M (encrypted with M’s public key), which with a specific configura-
then forwards the message to B. tion, and which are used
for illegal activities such
as trading drugs or weap-
Obviously, if only one message passes through the mix in this way, an observer can readily ons.
establish the relationship between A and B – one message comes from A to M, one mes-
sage leaves M and goes to B. This means that M must always process a large number of
messages, which it receives, reorders, and sends again so that no correlations can be
established externally. If need be, M accumulates a large number of incoming messages
and then forwards them all at once in a bulk action. To avoid replay attacks, a message
must also not be handled more than once by a mix, i.e., repeated messages must be sor-
ted out and discarded. Finally, it must be ensured that all incoming and outgoing mes-
sages are padded so that they have identical length, since otherwise correlations could
also be established based on the length of the messages.

If a mix is used as described, the relationship between sender and receiver is hidden,
except from the mix M itself and the sender of the message. In other words, a mix (if it
works correctly) only provides concealment for the relationship between sender and
receiver (unlinkability). To conceal the relationship even better, a sequence of mixes can
be connected in series - this is called a mix cascade.

6.4 Security in Mobile and Wireless

Communications
Mobile communication has gained enormously in importance in recent years. This is cer-
tainly due in large part to the popularity of smartphones, which have become the "Swiss
Army knives" of the digital age. One consequence is that many (especially younger) people
no longer have a telephone landline, but only use their mobile device to make calls – if
they make telephone calls at all in addition to instant messengers and similar offerings.

This section first outlines GSM technology as the basis of today's digital mobile networks.
Even though GSM is gradually replaced by newer protocols, the basic security concepts
remain the same.

This is followed by a look at the most important wireless in-house technologies: WLAN and
Bluetooth.

105
 Global System for Mobile Communications (GSM)

The GSM networks were the first public networks to provide encryption and other security
measures from the outset.

The main security measures provided by GSM networks are:

• Authentication of the subscriber or terminal device to the network,

• Encryption of the signaling and user data exchanged on the radio links,
• Anonymization of a mobile subscriber vis-à-vis an eavesdropping third party by means
of changing identifiers.

A GSM cell phone always requires a SIM card (Subscriber Identity Module). This is a smart
card of a smaller format that is inserted into the handset as a plug-in card. Among other
things, the SIM card carries a globally unique identifier, the IMSI (International Mobile Sub-
scriber Identity). Personal telephone numbers and short messages can be stored on the
SIM card. It also stores data relevant to security functions, such as the authentication algo-
rithm A3, the algorithm A8 required for key generation, a card-specific key kI required for
authentication with the network, and the IMSI. The algorithm A5 responsible for user data
encryption is stored on the device (cell phone), not on the SIM card.

The authentication procedure is based on an algorithm called A3 and works as follows:

When the user switches on his cell phone, they authenticate themselves to the device
(actually to the SIM card) with a PIN. If successful, the device registers with its IMSI with
the network concerned, which now verifies whether the device is allowed to log into the
network. If this is the case, the SIM card authenticates itself to the network using a chal-
lenge-response procedure as illustrated in the figure below. First, a 128-bit random num-
ber rand is sent to the cell phone. On the SIM card, algorithm A3 is applied to rand using
the key kI , and the result, called SRES (for "signed response"), is then sent back to the
network via the radio link. There – with knowledge of rand and kI – the expected response
is also calculated and compared with SRES. If they are the same, the authentication is
considered successful.

It is important to note here that the secret key belonging to the SIM card is never transmit-
ted for security reasons – not even if the subscriber wants to log on to a foreign network.
Instead, the authentication center of the home network, which knows this key, always
issues pairs of numbers, each consisting of a random number and the corresponding cal-
culated value.

106
Figure 25: Authentication in GSM

Algorithm A3 (as well as A8, which will be discussed shortly) is not generally specified;
each network operator can use its own procedure. Thus, every SIM card can actually only
authenticate itself in its own network. To make it possible to log on to other networks
despite this, the home network always generates a few pairs of rand and associated SRES
in advance and passes them on to the network in whose area the cell phone is currently
located, if necessary.

Since in GSM networks there is no authentication of the network against the cell phone, an
IMSI catcher is possible. This is a device that pretends to be a base station in a mobile net-
work in order to get hold of the IMSI or TMSI (this is a temporary IMSI). IMSI catchers are
used primarily by law enforcement and intelligence agencies to identify the cell phones
used by targeted individuals and then to create movement profiles of those individuals.
Some IMSI catchers are also able to put the cell phone into an unencrypted transmission
mode and thus listen in on conversations. In general, only law enforcement agencies are
legally allowed to own and use IMSI catchers.

After authentication, the random number rand and the secret key kI are also used to gen-
erate a key kC by means of an algorithm called A8, which is used to encrypt the payload
and signaling data on the radio link. This encryption is performed using algorithm A5.

In summary, algorithm A3 is used for authentication, algorithm A8 is used for key genera-
tion, and algorithm A5 is used for encryption. The choice of the specific algorithm A3 used,
which consists of the application of a one-way function, is left to each network operator. In
order for a subscriber to be able to log on to a foreign network (this is called roaming),
pairs of random number and expected response need to be transmitted from the home
network to the foreign network. The algorithm A5 used for encrypting the data on the
radio links is standardized throughout Europe. Without this uniform use of Algorithm A5,
the use of mobile devices in foreign networks would not be possible. There is, however, a
limitation: due to export restrictions on encryption technologies, different strength var-
iants of A5 are used in different countries.

It is also worth mentioning that a certain degree of anonymization takes place with GSM:
When a GSM device logs in, the IMSI of the SIM card is transmitted to the network's
Authentication Center. After that, a TMSI (Temporary Mobile Subscriber Identity) is
assigned and transmitted to the subscriber, but this is changed several times (e.g., with

107
 each location update). The subscriber device and network use only this TMSI for their
communication, so the IMSI is rarely transmitted. This ensures that listeners cannot easily
identify the subscribers, and, in particular, cannot create a movement profile.

WLAN

Small wireless networks are known as wireless LANs (WLANs for short), with the abbrevia-
tion LAN standing for Local Area Network as usual. The protocols used are also commonly
known as Wi-Fi. WLANs are widely used in companies and private households to provide
mobile access to the Internet for several computer systems or to enable computers to
communicate with each other in an easy way, without having to install network cables
everywhere. Because it is so easy to install, WLAN technology is also very suitable for tem-
porary networks (e.g., at an exhibition booth). There are also more and more hotspots.
With the help of a WLAN, a visitor to an airport, train station or café is offered mobile
access to the Internet (e.g., with a tablet or smartphone).

In principle, WLANs can be operated in two different ways, namely in infrastructure mode
or in ad hoc mode. In infrastructure mode, the participating devices communicate using
an access point, a kind of central radio bridge. This central access point is usually connec-
ted to other networks (such as the Internet) via cable and thus enables the individual devi-
ces to access the outside world. For example, the access point may be connected to the
Internet via DSL – in which case it is referred to as a wireless DSL router. In the less fre-
quently used ad hoc mode, two or more mobile devices communicate directly with each
other (peer-to-peer), without a central device. In each case, the individual participating
computer systems (clients) must be equipped with a wireless LAN device. Nowadays, this
is standard for notebooks, tablets and smartphones.

The detailed technical setup of WLANs is described in the international standards of the
IEEE 802.11x series. However, the security mechanisms defined there only relate to the
encryption of data on the radio link between the clients and the access points. Several
encryption methods have been developed for this purpose. The oldest is WEP encryption
(stands for: Wired Equivalent Privacy), which only offers very weak protection based on
the RC4 algorithm, but with very weak key management. WEP should therefore not be
used any more. Somewhat better is the WPA encryption (Wi-Fi Protected Access). How-
ever, today WPA2 in conjunction with a password, known as a pre-shared key (PSK), is con-
sidered the minimum standard for a secure WLAN. The PSK is a common key that must be
known to all WLAN participants. With its help, a specific session key is generated each time
a subscriber logs on to the network. In 2018, security was further improved with the new
WPA3 standard which does not need a PSK.

Another possible security measure for WLANs is the activation of the MAC address filter.
Here, the unique MAC address of each network card is used to only allow network access
to known devices. The MAC address can be read directly from most network cards, but it is
also possible to query it from the computer system using the card by issuing an appropri-
ate command.

108
Bluetooth

Bluetooth is a short-range radio technology, whereby devices equipped with a Bluetooth

interface can communicate independently. The main idea behind Bluetooth was originally
to replace cable connections, but it is also possible to set up small networks. Typical appli-
cations are data transfers between a personal computer and a tablet, a cell phone, or
input devices such as a computer mouse or keyboard. Bluetooth is also widely used
between a cell phone and a headset or loudspeaker. Bluetooth is based on simple proto-
cols and requires little power. As the range of Bluetooth has increased with new versions,
both Bluetooth and WLAN can be used for many applications today.

Bluetooth provides for authentication and encryption, which are implemented at the chip
level. The cryptographic processes used are based on so-called connection keys, which
are agreed between two Bluetooth devices during pairing. Authentication then takes place
using a challenge-response protocol. A special stream cipher is used for encryption, but
encryption is not generally required. There are different security levels that can be set by
the user, although many users work with the weakest level for simplicity's sake. A weak-
ness is also that user-selected (and possibly weak) PINs are used when generating the con-
nection keys.

SUMMARY
The complexity of modern digital communication networks – especially
the Internet – means that designing mechanisms to increase security in
these networks is a difficult task for which there are no unambiguously
best solutions. This involves ensuring the usual protection goals such as
authorization of access, authenticity, integrity, confidentiality and non-
deniability of messages, and in certain scenarios also the anonymity of
users.

Firewalls act as the "first line of defense" in today's networked systems

by inspecting data packets at network junctions and then allowing them
to pass or preventing them from being forwarded. There are several
types of firewalls that operate at different layers of the TCP/IP model,
each with its own advantages and disadvantages.

Communication security can also be located on different layers. The

main Internet standards for communications security are SSL/TLS,
which resides above the TCP layer, and IPSec, which belongs to the IP
layer and is, for example, used to establish virtual private networks.

A number of techniques are available that allow a user to remain (parti-

ally or completely) anonymous when using the Internet. On closer
inspection, a distinction can be made here between absolute anonym-

109
 ity, which cannot be lifted at all or only with unrealistically high effort (as
in the Tor network or the Mix technique), and partial anonymity, when at
least one server must be trusted (as in the Anonymizer).

Security measures are also integrated as standard in modern mobile

(cell phone networks according to GSM standard and its successors) or
wireless communication (WLAN, Bluetooth). Here, stream ciphers are
used for encryption.

110
 UNIT 7
SECURITY IN E-COMMERCE

STUDY GOALS

On completion of this unit, you will be able to ...

– discuss the usage of passwords for authentication.

– describe the concept of challenge-response protocols.
– explain the role of certificates in authentication.
– select suitable biometric procedures for authentication.
– illustrate the usage of smartcards for authentication.
 7. SECURITY IN E-COMMERCE

Introduction
Today, the term e-commerce or electronic commerce is used to describe the processes of
buying and selling transactions with the aid of the Internet. As a result, questions from
business administration as well as from computer science and law need to be addressed
in addition to IT security.

In the professional world, different subdivisions of the overall field of e-commerce are
made. For example, a distinction is often made between the areas of business-to-business
(B2B) and business-to-consumer (B2C). This lesson focuses on the B2C aspect with consid-
erations of email security as well as online banking and online payment systems.

7.1 Email Security

The exchange of email messages has become a matter of course in the working world as
well as in the private sphere and today is an important part of commercial communica-
tion. In the private sphere, however, chat services such as Whatsapp have now become
even more important.

From a technical point of view, the email service is an application located at the top layer
(the application layer) of the Internet's TCP/IP protocol family. The Simple Mail Transfer
Protocol (SMTP) is used between mail servers, and the user or their computer system uses
the Post Office Protocol (POP) or the more advanced Internet Message Access Protocol
(IMAP) to retrieve email messages. While these protocols originally do not contain any
encryption or other security features, TLS-based variants of these protocols have now
become widely used.

Transmitting an email message is often compared to sending a postcard. In fact, there are
parallels: An email message is entrusted to the Internet transport system in the hope that
it will reach its proper destination - much like the postcard you drop in the yellow mailbox
in Germany. The actual content of the email message is transmitted in plain text and can
thus be read by anyone who has access to the message.

So what threats are emails exposed to? Among other things, an attacker may be able to ...

• ... read any email.

• ... change the content of an email.
• ... change the name of sender or recipient.
• ... intercept and delete emails.
• ... attach malicious attachments to emails.

112
Mail technology originally did not include any security mechanisms that could prevent
attacks of the above kind. This is, of course, no longer acceptable in the age of e-com-
merce. There are two principally different approaches to dealing with these problems:

• Using the security features offered by email providers or special secure email services -
this does not require the user to make any changes to his computer system, but to trust
the provider and the effectiveness of its security mechanisms.
• End-to-end security by applying security features (such as encryption) before sending
the message – the sender and recipient must use additional software or make special
settings in their applications. There are two well-known protocols used for end-to-end
encryption of mails which will be discussed below: S/MIME and Pretty Good Privacy
(PGP)

Before investigating some of the mechanisms used to ensure the security of emails, let us
first have a look at how emails travel to get from sender to receiver.

Figure 26: Mail path from sender to receiver

The sender submits the email from the client to a Mail Transfer Agent (MTA) of the pro-
vider. From there, the email is passed, possibly via one or more intermediate MTAs, to the
Mail Delivery Agent (MDA) from where the receiver of the mail can collect it. In some cases,
for example, if both sender and receiver use the same mail provider, the initial MTA and
the MDA may coincide. A security challenge in this context is that the sender only has (limi-
ted) control over the initial MTA, and the receiver only has (limited) control over the MDA.
Neither the sender nor the receiver has control over the intermediate MTAs and the secur-
ity measures they do or do not take. In particular, they in general have no control over
whether and how well mails are encrypted when transferred between the different partici-
pants.

113
 Provider-side email security

To ensure that mails are adequately encrypted while in transfer, some providers have
decided to cooperate in groups so that they can guarantee that at least all mails within the
group are adequately encrypted in transfer and protected while at rest in between trans-
fers. An example of such a group is the German industry initiative “E-Mail made in Ger-
many” which guarantees users that their data is stored exclusively in secure German data
centers and that email messages are always transmitted in encrypted form. Even in this
case, however, there is criticism that it is not made sufficiently clear how the encryption
between the mail servers works precisely, i.e.: who generates the relevant keys, how they
are exchanged, and so on. Furthermore, the use of non-standard protocols makes it diffi-
cult for additional members to join the group (Zivadinovic, D. 2014).

End-to-end security using S/MIME or PGP

The MIME standard (Multipurpose Internet Mail Extension Protocol) is used to format mail
messages in such a way that different components such as text or multimedia attach-
ments can be separated from each other and thus clearly recognized. With the S/MIME
standard, the MIME types were expanded in 1998 to include security functions that permit
encryption and signatures. S/MIME is described in RFCs 2632 and 2633 and defines an
additional content type application/pkcs7-mime.

The second well-known software to support mail security, besides S/MIME, is Pretty Good
Privacy (PGP) which also allows users to encrypt and sign mails. Of course, decryption of
mails and checking of signatures is also supported. Like S/MIME, PGP uses asymmetric
encryption with a public and a private key.

In both S/MIME and PGP, senders can use their private key to sign their emails. The recipi-
ents then use the sender’s public key to verify the authenticity of the signature. If the
result is positive, they can be sure that this email is from the claimed sender. Additionally,
the sender can use the receiver’s public key to encrypt the emails. In this case, the emails
are not directly encrypted using the public key, but a hybrid protocol is used instead: the
emails are encrypted using a symmetric method and an individually generated key, similar
to a session key. This key is then encrypted using the asymmetric method and the receiv-
er’s public key. Using this hybrid protocol makes encryption far more efficient, and addi-
tionally makes the handling of mails for several recipients much easier.

The public key can be transmitted through an email, for example. However, there are also
key servers where the public keys of PGP users are stored. While S/MIME uses X.509 certifi-
cates issued by some certification authority to ensure the authenticity of public keys, PGP
uses a decentralized so-called "web of trust" where users certify the public keys of other
users, and public keys are trusted if a sufficient number of such certifications are provided.

Since the original PGP standard was based on the patented RSA algorithm, following a
proposal by Phil Zimmermann it was decided in 1997 to standardize it asOpenPGP
(defined in RFC 4880), using encryption algorithms without licensing restrictions. Because
of the strength of PGP, it was originally considered as an armament, and criminal investi-

114
gations were started against Phil Zimmermann for violating arms export control regula- Phil Zimmermann
tions. Eventually, these investigations were dropped. A widely used implementation of born 1954, is an US-Amer-
ican computer scientist
OpenPGP is GnuPG which is available as open source. and cryptographer mainly
known for creating the
Although email has become an important tool for communication today, end-to-end PGP software and proto-
cols. His goal was to pro-
encryption to ensure confidentiality is still not widely used. The main reason for this is vide users worldwide with
that end-to-end encryption requires some basic understanding of the concepts involved a secure system for email
communication.
and therefore is difficult to use for non-technical users, as shown in a study in 1999 which
still applies today (Whitten, A. & Tygar, J.D. 1999).

Email authentication

One of the challenges of email is that it is very easy to forge the sender’s name and
address (“email spoofing”), since the standard Simple Mail Transfer Protocol SMTP does
not contain any checks regarding the sender’s name and address. This weakness can for
example used for phishing or to distribute spam mail. The “Domain-based Message
Authentication, Reporting and Conformance” (DMARC) authentication protocol has been
introduced to address this challenge. At its core, DMARC consists of the “Sender Policy
Framework” (SPF) and the “DomainKeys Identified Mail” (DKIM).

• Sender Policy Framework (SPF) uses the Domain Name Service (DNS) to enable mail
servers to check whether an incoming email claimed to originate from a certain domain
was indeed sent from an IP address authorized to send mails for this domain.
• DomainKeys Identified Mail (DKIM) similarly allows sending mail servers to digitally sign
any mails originating from the server. A receiving mail server can check, using the pub-
lic key of the domain’s mail server, whether a mail received was indeed sent from the
claimed domain.

The owner of a domain used for sending email can define, as part of their DNS record,
whether emails from this domain use SPF, DKIM, or both, and what should be checked for
mails claiming to come from this domain. Additionally, the definition states what receiving
email servers should do with any mails that fail the relevant checks. In this case, mails
may be delivered anyway (possible with some form of warning), they may be put into
quarantine, or they may be rejected.

Usage of DMARC is expanding, but since both the sender’s and the receiver’s email server
as well as the DNS servers used need to cooperate, this is a slow process. Additionally,
there are a number of technical difficulties such as the handling of mailing lists which can
be resolved, but not all mailing list tools are able to do so.

Spam email

Spam emails are another problem, making up a considerable percentage of all email sent
today. This is email sent en masse, usually with commercial content, which the recipient
does not want to receive and considers annoying. As a rule, such emails do not represent a
security problem in the narrower sense, since no data is disclosed or changed by their
mere receipt. A genuine problem is posed by phishing emails, which attempt to lure an
Internet user via a link to a fake website (e.g., the fake website of a bank) and to get him or

115
 her to divulge some secret (e.g., by entering a password). Warnings against such phenom-
ena have been issued again and again for quite some time, so few users "fall for it" nowa-
days. However, some still do, and since the effort for this type of attack is fairly low, in total
this type of attack still seems to be worth the effort from the attacker’s point of view.

7.2 Online Banking and Online Payments

The term “online banking” refers to the processing of banking transactions via electronic
communications networks, which today generally means the Internet, although telephone
calls can also be included. Alternative terms are home banking or electronic banking.

Online banking can usually be performed using special apps or other programs, some-
times bank-specific, or the connection is established with a common browser via the
bank's website, using the well-known SSL/TLS protocols to secure the connection. Often, a
combination of these is used for two-factor authentication (2FA), and within the European
Union the use of 2FA has been introduced as a requirement starting in 2021 by the Revised
Payment Services Directive (PSD2).

After the user has logged in (by entering a PIN), an additional transaction number (TAN) is
used for each transaction (transferring a sum of money, setting up a standing order, etc.).
Regarding TANs, there has been an evolution from simple TAN lists to indexed TAN lists
and mTANs to the current chipTANs, photoTANs and other similar procedures.

Credit cards on the Internet

Payment by credit card has become widely used, and in the past the Secure Electronic
Transaction (SET) communication protocol was used to ensure the security of credit card
payments. However, SET is no longer supported by credit card companies.

Payment by credit card has become widely used, but such payments present major secur-
ity challenges that need to be addressed. Apart from the secure transfer of credit card data
between seller and buyer, which usually can be implemented using standard encryption
algorithms, an additional difficulty consists in the multiple parties involved. If a customer
wants to buy something in a shop paying by credit card, the customer may try to use a
fake or stolen credit card – possibly while the internet connection of the shop is down. The
shop, on the other hand, may later try to modify the amount to be paid, or it may try to
store the credit card data and use them to initiate additional payments later. (The banks
and credit card companies involved are usually considered trustworthy, but even this may
not always be adequate.)

Compared to credit card payments in a shop, payment on the internet is even more chal-
lenging since in this case, it is impossible to check the physical credit card itself.

To address these security challenges, different approaches are used:

116
• The Payment Card Industry Data Security Standard (PCI-DSS) defines technical and
organizational measures for ensuring security and applies to cases where credit card or
payment data are stored or processed. Any organization that wants to accept credit card
payments must contractually agree to set up suitable security controls according to the
standard. For example, the standard does not permit the storage of sensitive authenti-
cation data such as the card verification code (CVC) (PCI Security Standards Council Card Verification code
2022, p. 80). The CVC is used to verify that the payer indeed has access to the credit (CVC)
also known under similar
card. To do so, it is not allowed to store the CVC after completing a transaction, and only names such as Card Veri-
the card issuer is able to verify the CVC. fication Value CVV, is a
• A technical specification for smart payment cards as well as the payment terminals that three or four digit number
printed on credit cards
handle such cards is contained in the EMV standard, named after the three companies that is used for “card not
Europay, Mastercard and Visa that defined this standard. It refers to smart cards con- present” payments with a
credit card, for example
taining a processor chip which replaced the earlier payment cards with magnetic strips.
online payments.

Luhn check digit algorithm

When writing down a number such as a credit card number, it is easy to make a mistake
such as mis-copying a digit, swapping two consecutive digits, or leaving out a digit alto-
gether. A simple algorithm to check for such mistakes is the Luhn algorithm which is used
for credit card numbers as well as various other applications such as the International
Mobile Equipment Identity (IMEI), a unique identification number for mobile devices, or
the vehicle identifying number defined by the International Union of Railways (UIC).

The Luhn algorithm works as follows: given a number (such as the credit card number
without the check digit), one adds the values of the individual digits of the number, start-
ing from the right and doubling the first, third, fifth etc. digit. If doubling a digit results in a
two-digit number, the sum of the digits is used in the addition. Of the resulting number n,
the last digit d is calculated, and 10 − d is used as check digit and appended to the origi-
nal number. In order to validate the resulting number, the same algorithm is used, except
that the second, fourth, sixth etc. digit are doubled. The number is valid if the calculated
check sum is divisible by 10.

An example: starting from the number 1234543,

n = 1 · 2 + 2 + 3 · 2 + 4 + ds 5 · 2 + 4 + 3 ,
· 2 = 2 + 2 + 6 + 4 + 1 + 4 + 6 = 25
where ds stands for the sum of digits. The last digit is d = 5, and the resulting check digit is
10 − 5 = 5. This leads to the number 12345435, and
n = 1 · 2 + 2 + 3 · 2 + 4 + ds 5 · 2 + 4 + 3 .
· 2 + 5 = 2 + 2 + 6 + 4 + 1 + 4 + 6 + 5 =
30
Since 30 is divisible by 10, the number is valid.

This check algorithm protects against many accidental errors, in particular against most
swaps of adjacent digits, as well as single-digit errors. However, it does not protect against
any deliberate attacks.

117
 Paypal

Paypal is now the most widespread online payment system for small and medium
amounts, with several hundreds of millions of users. The company Paypal Holdings, Inc.
belonged to ebay for a time and has been independent again since 2015. The user (the
Paypal member) has a virtual account with Paypal that is linked to the email address and
there is no additional account number. However, the Paypal account is linked to one or
more conventional bank accounts, and there are several ways to charge the Paypal
account or use it to process payments. With the help of the Paypal account, payments can
be made as well as received. A great advantage of processing via Paypal is that a credit
note is issued immediately. When buying on the Internet, this can shorten the delivery
time, since the dealer does not have to wait for the arrival of a bank transfer if payment in
advance is desired.

As usual, SSL/TLS is used for the transfer of data. As expected from the point of view of
data economy, the financial data of the payer remains hidden from the recipient. If a
buyer wants to pay for an online purchase, he is transferred from the shop system to the
Paypal system, and logs in there, possibly with a completely different identity. The shop
system eventually gets the confirmation that the payment was successful, but receives no
additional information about the account used.

For payments within the EU, Paypal is required to follow the PSD2 regulation, in particular
to use 2FA. The standard approach used by Paypal is to align a telephone number with
each account, and to send a TAN via SMS to the account holder to confirm payments.
However, such an SMS TAN is not needed when a device is used that is considered trust-
worthy because the user has confirmed it previously (using the SMS TAN mechanism).

7.3 Electronic Money

In the previous sections of this unit, we always discussed the online transfer or payment
using "regular money" such as Euros or US Dollars, issued by a government or similar
entity. Electronic money, on the other hand, consists of electronic data which themselves
function as money or at least represent this. There have been numerous variants of this to
date, with the aspect of anonymity often playing a major role - analogous to conventional
cash – coins and banknotes. Essentially the same concept has become widely known
recently as “digital currency” or “cyber currency”, for example the BitCoin system dis-
cussed below (which however supports only pseudonymous payment, not anonymous
payment).

The core requirement that needs to be addressed by all concepts used as electronic
money concerns the prevention of multiple spending: in general, it is easy to copy elec-
tronic data an arbitrary number of times. If these electronic data are to represent money,
it is important to ensure that it is not possible to spend this money multiple times by copy-
ing the data.

118
A second requirement for electronic money is anonymous payment. Payments in cash Anonymous data
can in principle be performed anonymously, and in many cases are. If you pay for your are data for which it is
impossible to identify the
shopping in a supermarket using cash, the supermarket in general will not know who you person that these data
are, and there is no need for knowing the identity of the customer. There are some excep- refer to, at least in theory.
tions to this, mainly concerning payments of large amounts, where the seller may want to (Using modern data sci-
ence methods, it turns
know the customer’s identity, for example because of the risk of receiving forged money, out to be exceedingly dif-
or the seller may be obliged to check their identity to prevent money laundering. How- ficult to modify data such
that the relevant person
ever, these are exceptions implemented using additional organizational rules but cash
is no longer identifiable,
payment in general is anonymous. Payment by bank transfer or credit card, on the other but the data are still use-
hand, by default is non-anonymous, but a limited amount of anonymity can be achieved ful.)
because there is a trusted third party (intermediary) between the sender and the receiver
of a payment. Payment systems can now be set up in such a way that the receiver does not
need to know the sender, and the intermediary does not need to know what the payment
is for – but will in general know both the sender and the receiver of the payment.

From a data protection perspective, anonymous data are the counterpart to personal data
that refer to an individual person and need to be protected accordingly.

One of the first systems for electronic money was the eCash system by DigiCash in the
1990s which satisfied both requirements described above based on the concept of “blind
signatures” (Chaum, D. 1983). However, this was not a commercial success and the com-
pany eventually went bankrupt.

Cryptocurrencies

All the systems described so far are ultimately based on conventional currencies. There-
fore, there is always a need for the users to trust the intermediaries, mainly (central or
other) banks, that they will exchange users’ claims for regular money (e.g. cash). Crypto-
currency has tried to move away from this need for a trusted intermediary. The goal is that
users do not have to trust each other either; every transaction is simply logged and docu-
mented. The name "cryptocurrency" comes from the fact that cryptography principles
play a major role in the technical implementation. To understand the principle of crypto-
currency, let us design the following scenario in a thought experiment:

• A group of individuals and companies distributed around the world agree to pay each
other when exchanging goods or services using virtual vouchers whose respective own-
ers are recorded on the Internet in a large database - a kind of collective accounting sys-
tem.
• There is a marketplace where these vouchers can be exchanged for regular money (or
other goods). The corresponding rate may fluctuate daily.

The vouchers of this scenario can be seen as a kind of currency. Through the marketplace
with the possibility of exchange into regular money, a connection to the currency system
of the banks exists, but it is crucial that when paying purely with the vouchers, the banks
(and the relevant governments) are not involved. Cryptocurrency is such a voucher sys-
tem. Of course, sophisticated encryption mechanisms must be used so that only legiti-
mate data are "real" vouchers and represent the currency.

119
 Bitcoin

The oldest and best-known cryptocurrency is Bitcoin, which was first described in 2008 by
one or more authors under the pseudonym Satoshi Nakamoto (Nakamoto 2008). At the
core of this system is a so-called blockchain, which is a data structure which records who
(identified by a public key) is currently in possession of a bitcoin. By using the blockchain,
this global decentralized database ensures that all transactions of all participants are
recorded in a digital account statement. The participant identified by a public key remains
Pseudononymous data pseudononymous. Anyone who knows the necessary private key and the corresponding
are a weaker form of permission can transfer property to another user with a simple entry in the chain. There is
anonymous data. In con-
trast to anonymous data, no need for a central intermediary such as a bank to process a transaction; instead, every
they still have a link that transition is recorded in the chain and immediately sent as a copy to all computers that
allows authorized people are part of the system. In BitCoin, many transitions are collected from different partici-
to identify the relevant
person. From the point of pants and added to the blockchain as one block.
view of unauthorized
people, pseudonymous
The public key thus forms a pseudonym of the persons involved. Everybody can see that a
data behave like anony-
mous data. certain payment was issued from (or received by) a certain public key, and whoever knows
the owner of a public key also can relate all relevant payments to this owner.

The general principle of such a blockchain is shown in the figure. The basic idea is an
expandable list of data records whose integrity is ensured by the fact that a data record
always also contains the hash value of the preceding data record.

Figure 27: Basic structure of a blockchain

Once a new block is to be added, in principle every participant is allowed to do so by cal-

culating the hash value of the header of the previous block, with the additional restriction
defined in Bitcoin that a nonce has to be selected in such a way that the hash value starts
with a defined number of zeroes. This activity is called “mining”. The number of zeroes is
adapted over time in such a way that finding the suitable nonce takes on average about 10
minutes. So if more (or less) computing power is used worldwide for mining, the required

120
number of zeroes is increased accordingly, and the system continues to grow at a speed of
on average one block every 10 minutes. Successful miners then get a certain number of
BitCoins as an incentive to pay for the computing effort involved. This consent mechanism
used by BitCoin is called “proof of work” (PoW), because participants can prove, by show-
ing the suitable nonce, that they have spent a certain amount of work and therefore have
a claim that their block is to be added.

Since possibly multiple miners might find a suitable nonce more or less at the same time,
some mechanism is needed to define which of the alternative blockchains is considered
the valid one. In proof of work, the rule is that the longest blockchain is considered valid. If
several blockchains are the same length, temporarily all of them are valid until one of
them is extended with another block and becomes the only valid one.

If an attacker manipulates any entry in the blockchain, this becomes visible since the
resulting hash value is no longer correct. Of course, the attacker might try to modify this
hash value as well, but this takes considerable time and effort, and the attacker is unlikely
to ever turn “their” blockchain into the longest one. An exception occurs if the attacker
controls more than half of all resources in the network. In this “51%-attack”, the attacker
might be able to overtake the legitimate blockchain and thus modify older entries. While
such an attack is rather unlikely in a large network such as BitCoin, it is quite possible in
smaller networks of other blockchains and these attacks occur regularly.

Considering BitCoin as a currency, it has received mixed receptions. On the one hand, it is
a technically convincing approach to transferring money between participants without a
need for a bank or other intermediary. On the other hand, there has been a lot of specula-
tive investment, and the value of BitCoins has fluctuated enormously. Even more impor-
tantly, the possibility to transfer money pseudonymously has led to BitCoin becoming the
standard currency for payments in illegal transactions such as payment for drugs and
weapons, or in ransomware attacks and other forms of blackmail.

It is also interesting to note at this point that "blockchain technology," which originated in
the world of Bitcoins, is now being discussed as a general principle that could revolution-
ize the financial system and radically change the way we deal with property. The basic
idea: It is permanently recorded in a huge database who owns what at any given time.
What role does money play then?

However, blockchains are also discussed simply as another type of database. They are
interesting for those types of applications where it is important to store data in a correct
order that cannot be changed afterwards. Companies such as IBM and Microsoft now offer
service models to better solve certain types of business problems with blockchains.

SUMMARY
The exchange of email messages plays a significant role in e-commerce
today. Therefore, email security – especially the confidentiality of com-
munication and authentication of senders – is of great importance.

121
 There are different approaches to this: security can be ensured by the
providers, mainly based on TLS; a different approach is end-to-end
encryption of mail which ensures protection independent of providers
and other intermediate parties but is more difficult to use. More
recently, different mechanisms for authentication of senders have been
set up.

The issue of money in the online world has different aspects. Online
banking is about doing standard banking transactions (such as trans-
fers) over the Internet. The need to make an online payment in a secure
way arises from the explosion of online shopping. Finally, another devel-
opment is electronic money, where the data itself represents the value -
in the case of Bitcoin, even detached from conventional money. The
blockchain technology first used for Bitcoin is now also being used in
other areas.

122
 UNIT 8
SECURE SOFTWARE DEVELOPMENT

STUDY GOALS

On completion of this unit, you will be able to ...

– analyze and model security threats in software development.

– discuss the main techniques for secure software design.
– explain the OWASP Top Ten security risks.
 8. SECURE SOFTWARE DEVELOPMENT

Introduction
One of the main causes of the vulnerability of IT systems and networks lies in the faulty
programming of the software used. Consider for example a web application that allows
arbitrary commands in a user input field instead of restricting it to plain text input (e.g.,
user name). Other causes are conceptual weaknesses (examples: unprotected data trans-
mission on the Internet, inadequate protection of operating systems) and errors in the
configuration of systems and services, plus, finally, incorrect behavior on the part of the
user – a well-known example: clicking on links in email messages with unknown senders.

The topic of "secure software" has become firmly established in the field of IT security,
and it is also becoming more and more firmly anchored in courses on software develop-
ment at universities. In this context, secure software should be understood as software
that is protected against intentional attacks – protection against malfunctions or acciden-
tal external influences is just as important but not considered in this context. It thus goes
beyond the concept of reliable software which is protected against accidental influences.

As in other areas, it is also true here that subsequent repair of problems is usually associ-
ated with far greater expense than the timely inclusion of security aspects.

How do you develop secure software? It is obvious that, roughly speaking, the following
phases are relevant which will be addressed in the remainder of this unit:

• Analysis of possible threats and elaboration of security requirements,

• Design of secure software,
• implementation of secure software.

8.1 Threat Modeling

In order to incorporate security considerations into all phases of the software develop-
ment process, Microsoft has created a concept called the Security Development Lifecycle
(SDL). Some of the methods and tools developed as part of SDL have found wide accept-
ance in software development. This is particularly true for threat modeling. Here, the
STRIDE classification has become established as a widely used classification of threats.
The abbreviation STRIDE is derived from the first letters of the threats:

• Spoofing threats: hiding the identity of an attacker

• Tampering threats: manipulation of data or systems
• Repudiation threats: disputing that an activity or statement was performed by the
attacker
• Information disclosure threats: breaking the confidentiality of data or systems
• Denial of service threats: making access to a system or data difficult or impossible

124
• Elevation of privilege threats: gaining elevated privileges within a system by exploiting a
vulnerability

Once the potential threats are identified, the next step is to assess them. Microsoft devel-
oped DREAD as a simple method for assessing vulnerabilities – the five letters stand for
Damage, Reproducibility, Exploitability, Affected Users and Discoverability. When assess-
ing a threat, each of the five items is assigned a value from 1 (low) to 3 (high), and then the
sum of the values is used. Unlike other threat assessment methods, the probability of
occurrence of a threat is not taken into account here. However, the DREAD method is now
considered too simple and is no longer used even by Microsoft.

There are various current and widely used techniques for modelling threats and rating
risks, such as the NIST approach to risk assessments (NIST National Institute of Standards
and Technology, 2012) or the OWASP Threat Modeling Process, consisting of the following Open Web Applications
steps (Conklin, 2022): Security Project
(OWASP)
is an online community
• Step 1: Decompose the Application. This step is about understanding the application that was originally set up
and its interactions with external entities. as a project to collect
ideas and concepts about
• Step 2: Determine and Rank Threats. Here the STRIDE model can be used to identify and the secure development
categorizes the threats involved. To rank the threats, the probability of a threat being of web applications.
Today, it has become a
exploited needs to be considered.
registered non-profit
• Step 3: Determine Countermeasures and Mitigation. Once the threats have been identi- organization. Its focus still
fied, one needs to define and implement counter-measures that will mitigate these is on web applications
but it also addresses
threats. other types of applica-
tions and their security.
Risk assessment

Risk is defined as a potential damage which may occur but has not occurred yet. The
assessment of risks is therefore usually based on the two parameters probability and
impact of the damage. Since in practice, it usually is impossible to give exact quantitative
values for these parameters, qualitative values are commonly used, e.g. using four levels
as follows:

Table 1: Sample qualitative risk assessment

Sample qualitative risk assessment

Probability

low medium high Very high

Impact Very high 2 3 4 4

high 1 2 3 4

medium 0 1 2 3

low 0 0 1 2

Source: Ralf Kneuper (2024)

125
 8.2 Secure Software Design
There are various models that can be used for the secure design of software, for example
the NIST Secure Software Development Framework (SSDF) (NIST National Institute of
Standards and Technology, 2022) which defines a set of relevant practices organized into
four groups as follows:

• Prepare the Organization (PO): these practices define what needs to be done before
software development itself starts, such as defining the security requirements, imple-
menting roles and responsibilities, or implementing a supporting toolchain.
• Protect the Software (PS): these practices define the protection of the software itself, in
its various formats (such as source code, installation packages) against unauthorized
access or tampering.
• Produce Well-Secured Software (PW): these practices refer to the core of secure soft-
ware development, including the design of the software such that all security require-
ments are addressed, as well as reviews, tests and other forms of verification to later
ensure that this was done correctly.
• Respond to Vulnerabilities (RV): once a system is in productive use, it is important to
monitor it, identifying and handling any vulnerabilities that may occur.

An important practice contained in PW is “Reuse Existing, Well-Secured Software When

Feasible Instead of Duplicating Functionality” (PW.4), which is particularly important for
any security or cryptographic functionality. The reason for this practice is the high risk of
implementation errors in implementing even well-known algorithms, overlooking some
apparently minor aspects which may lead to breaking the security of the entire algorithm.
It is therefore strongly recommended never to implement any such algorithms oneself if
they are to be used for productive systems but to use suitable, preferably widely used and
checked libraries instead.

An approach to the secure design of networked systems that is increasingly used is the
zero-trust model (which is only mentioned as an example in SSDF). The core idea of zero-
trust is to assume, for any component of a system, that all other components are not trust-
worthy but may have been compromised even if they are part of the organization’s own
environment. As a result, all data received from other components must be validated and
the sender authenticated and authorization checked, independent of whether the sender
component is part of the internal network.

Apart from the models discussed, there is a number of general guidelines that should be
used for secure software design:

• Use several lines of defense against attacks: since an attacker may overcome the first
line of defense such as a firewall, it is recommended to ensure that even then the
attacker only has limited opportunities to steal data or create damage, without having
to overcome additional protection systems.

126
• Do not implement cryptographic functions for production use yourself: there is a high
risk of overlooking important but hidden security risks in any cryptographic algorithm,
such as the selection of certain parameters. Therefore, one should always use one of the
widely available libraries for such functions which have been created by specialists and
thoroughly tested (cf. practice PW.4 from SSDF as described above).
• Use a genuinely random source for generating secrets: if a secret such as an encryption
key is not generated randomly, an attacker might use the information about the genera-
tion process to identify the secret or at least reduce the search space.
• Keep the system secure even in case of failures: sometimes, a computation will fail, pos-
sibly due to a programming bug or to incorrect input data (deliberate or accidental). In
such cases, the system should not fail itself, resulting in an undefined and possibly inse-
cure state, but catch the failure and handle it appropriately, for example by reporting an
error.
• All input data must be checked and validated before further processing. It is not suffi-
cient to perform this check on the client, which may be compromised and controlled by
an attacker, but the check must (also) take place on the server.

8.3 Techniques for Secure Programming

Many security errors can also be made in the implementation phase of a software devel-
opment project – one of the best-known errors probably is the "buffer overflow". The
types of implementation errors are often specific to a particular programming platform,
such as a programming language or an operating system. In order to avoid implementa-
tion errors, it is of course best to choose a "secure" programming language. But what is a
secure programming language?

The individual programming languages set different priorities here. The C programming
language, for example, focuses on runtime efficiency and hardware proximity, while the
programming languages Java and in particular Ada emphasize error-proofing and also
attack-proofing. The situation is completely different for PHP which is widely used for web
pages and emphasizes simple usability above all even at the expense of security. If the
programming language for a new development project has not yet been fixed yet, the
security of the language should also be a decision criterion.

Independent of the programming language used, a major source of security problems, in

particular for web applications, is the processing of input data (or data from some other
non-trustworthy source) without adequate checking of syntax and length. This can for
example be used by an attacker to cause buffer overflows (if the input data are longer than
expected) or for injection attacks if the input data have an inadequate syntax format.

SQL Injection

A common form of injection attacks is the SQL injection where an attacker enters data into
a text input field which uses suitable syntax such that it is then interpreted as SQL code.

The most important SQL statement is the following simple SELECT statement:

127
 SQL SELECT <attributes> FROM <table> WHERE <condition>
is a language used for
expressing queries in rela-
tional databases. A com- From the database table, this statement selects all data records that satisfy the condition
mon way of using SQL is and displays the defined attributes of these records.
to generate an SQL query
as a string in some pro-
gram and send this string An example for an injection attack based on the SELECT statement: the following little
via an interface to the
program reads a string from the console which is interpreted as the customer id. In the
database to execute it.
next step, a SQL query is generated (as a string) that will select and show all data fields
from this customer’s record. This string can then be sent to a database where the query is
executed.

strCustId = getInputString("CustId");
strSQL = "SELECT * FROM Customers WHERE CustId = " + strCustId;

Now what happens if an attacker, instead of entering the customer id, enters the text
“John OR 1=1”? The resulting SQL query will be

SELECT * FROM Customers WHERE CustId = John OR 1=1

Since “1=1” always is true, the WHERE-condition is always evaluated to true and SQL
query will return all records for all customer entries in the database, not just John.

Alternatively, the attacker could enter the text “John; DROP TABLE Customers”. In this
case, after displaying the data stored about customer John, the database will drop
(delete) the table Customers including all its data. Similarly, many other SQL statements
could be added after the customer name; for example, the input “John UNION SELECT
UserId, Password FROM Users” will return, in addition to the data about customer John,
all user IDs and password from the Users table.

Such an SQL injection is not necessarily based on an explicit input field. For example,
some web applications use a URL to select and display data as in the following example:
when clicking on a certain link, the URL https://myshop.com/Products?type=books
is sent to the server which converts it to the SQL query

SELECT * FROM Products WHERE type=’books’

In this case, the same type of attacks is possible by editing the URL that is sent to the
server.

As a first step to protect against SQL injection attacks, it is important to validate any input
data coming from a non-trusted source such as a user input field before processing them.
Many programming languages contain suitable libraries and functions to implement such
checks. In Open Web Application Security Project (2021a), (OWASP) describes some fur-
ther techniques to protect against SQL injection.

128
Although so far, we only talked about SQL injection, the basic type of injection attack is
also possible in other contexts where untrusted data are processed, for example when
user input is used for building an HTTP response. Again, the main protection is to always
validate user input before handling it any further.

OWASP Top Ten

OWASP has prepared a top ten list, last updated in 2021, which consists of the following
ten vulnerabilities that are often seen in Web applications (Open Web Application Security
Project, 2021b):

• A1:2021—Broken Access Control: restrictions on what authenticated users are allowed

to do are often not properly enforced. Attackers can exploit these flaws so that they can
have unauthorized functionality and/or data, such as access to other users’ accounts
and sensitive files, the ability to modify other users’ data, or permission to change
access rights.
• A2:2021—Cryptographic Failures: many web applications and APIs do not properly pro-
tect sensitive data such as financial, healthcare, and PII, applying cryptography either
incorrectly or not at all. For example, they use algorithms and protocols that are weak
or inadequate to the task, or weak keys. Attackers may steal or modify such weakly pro-
tected data to commit credit card fraud, identity theft, or other crimes. Without extra
protection such as encryption at rest or in transit, sensitive data may be compromised
and require special precautions when exchanged with the browser.
• A3:2021—Injection: injection flaws such as SQL, NoSQL, OS, and LDAP injection may
occur when untrusted data is sent to an interpreter as part of a command or query, usu-
ally after passing on data from some user input field without verification. The attacker’s
hostile data can trick the interpreter into executing unintended commands or accessing
data without proper authorization. Cross-site scripting (XSS) attacks, where an attacker
manages to cause malicious scripts to be executed on other clients visiting the same
website, are now counted as a special case of injection attacks by OWASP.
• A4:2021—Insecure Design: even a perfect implementation of a web application will be
insecure if it is not based on a secure design, for example leaving out important security
controls. To achieve a secure design, tools such as threat modeling, secure design pat-
terns and principles, and reference architectures should be used.
• A5:2021—Security Misconfiguration: security misconfiguration usually is a result of inse-
cure default configurations, unnecessary open ports or services, misconfigured HTTP
headers, and verbose error messages containing sensitive information. All operating
systems, frameworks, libraries, and applications must be securely configured, as well as
patched and upgraded in a timely fashion.
• A6:2021—Vulnerable and Outdated Components: components such as libraries, frame-
works, and other software modules run with the same privileges as the application
itself. If a vulnerable or outdated component is exploited, such an attack can facilitate
serious data loss or server takeover. Applications and APIs using components with
known vulnerabilities may undermine application defenses and enable various attacks
and impacts.
• A7:2021—Identification and Authentication Failures: application functions related to
authentication and session management are often implemented incorrectly, allowing
attackers to compromise passwords, keys, or session tokens, or to exploit other imple-

129
 mentation flaws in order to assume other users’ identities temporarily or permanently.
Examples involve allowing weak passwords, permitting brute force or other automated
attacks, and weak processes for forgotten passwords.
• A8:2021—Software and Data Integrity Failures: if software and data are transferred
between environments, their integrity must be verified, e.g. using signatures. This
applies e.g. to moving code along the CI/CD pipeline, downloading updates, or insecure
Serialization and deseri- deserialization.
alization • A9:2021—Security Logging and Monitoring Failures: insufficient logging and monitoring,
Serialization is the proc-
ess of converting objects coupled with inadequate filtering of log data and missing or ineffective integration with
into a linear (serial) for- incident response, allows attackers to further attack systems, move on to additional
mat such as a text string. systems, and tamper, extract, or destroy data. Most breach studies show that the time it
Deserialization is the
process of converting takes to detect a breach is over 200 days, and they are typically detected by external
such a linear format back parties rather than by internal processes or monitoring.
into the object. • A10:2021—Server-Side Request Forgery (SSRF): in SSRF, an insecure server is used to
send HTTP requests to some system that the attacker cannot access directly. For exam-
ple, the server is induced to connect to an external system and leak information such as
login credentials to the attacker. Commonly, an SSRF attack can be performed if the
server is trusted by a third system to send requests that contain an URL. In such a case,
an attacker may try to modify the URL or some other part of the request, causing the
recipient server (which may be the same as the original insecure server) to read or mod-
ify internal resources.

8.4 Integrating Security Into Projects

When running a project in the context of information security (or privacy), either address-
ing a specific security task or including security aspects into a more general project, one
typically needs to include the following steps (Kneuper, 2018, p. 142):

• Perform a risk or threat analysis, identifying and evaluating the relevant protection
goals, risks and/or threats. What do you want or need to protect against? For this step,
the OWASP Threat Modeling Process, possible in combination with the OWASP Top Ten
CVE or a CVE database, can be used.
CVE (Common Vulnerabil-
ities and Exposures) is a
standardized system for • Identify the requirements that need to be implemented in order to address the identi-
the consistent naming of fied risks and threats. In many cases, it is necessary or at least useful to use relevant
vulnerabilities and expo- standards for this (as well as the following) step. When doing so, it is important to start
sures in information
security. with the standards themselves rather than any secondary summaries that may be
incomplete or out of date.
• Define measures to implement the requirements identified. In many cases, there will be
different measures to do so. In such a case, one should not use the first solution that
comes to mind but systematically think about possible solutions, evaluate them, and
select the best solution based on this evaluation.
• Implement these measures.
• Ensure traceability, showing for each requirement that and how it is implemented. This
is usually done using a traceability matrix, mapping table or similar.

130
Table 2: Simple example of a traceability matrix

Simple example of a traceability matrix

Requirement Implementation

ISO/IEC 27001

• Requirement 1 Summary of Implementation of req.1

• Requirement 2 Summary of Implementation of req.2

• Requirement 3 Explanation why not relevant

• ... ...

PCI-DSS

• Requirement 1 Summary of Implementation of req.1

• Requirement 2 Summary of Implementation of req.2

... ...

Source: Ralf Kneuper (2018).

• Finally, thoroughly check the resulting system to ensure that the measures are imple-
mented correctly (verification) and all risks and threats are addressed adequately (vali-
dation).

SUMMARY
The development of secure software has become a central field within
software development and security is now understood as an important
element of software quality. Roughly, the topic can be divided into
threat modeling, secure software design and secure programming,
where the last two topics, including the methods and practices applied
there, are not always sharply distinguishable from each other.

Different bodies and communities of interest are working on the topic of

secure software. As a result of these efforts, several lists of rules to be
observed or of common vulnerabilities have emerged. One highly regar-
ded list is the OWASP Top Ten list of the Open Web Applications Security
Project.

131
BACKMATTER
 LIST OF REFERENCES
The Apache Software Foundation (2022). Password Formats. https://httpd.apache.org/doc
s/2.4/misc/password_encryptions.html

Buell, D. (2021). Fundamentals of Cryptography. Springer.

Chaum, D. (1983). Blind Signatures for Untraceable Payments. In: Chaum, D., Rivest, R.L.,
Sherman, A.T. (eds) Advances in Cryptology. Springer, Boston, MA.

Conklin, L. (2022). Threat Modeling Process. https://owasp.org/www-community/Threat_M

odeling_Process

Kneuper, R. (2018), Software Processes and Life Cycle Models. Springer Nature.

Math Explorer’s Club (2004). English Letter Frequency (based on a sample of 40,000 words).
Cornell Dept. of Mathematics. https://pi.math.cornell.edu/~mec/2003-2004/cryptogra
phy/subs/frequencies.html

Nakamoto, S. (2008): Bitcoin: A Peer-to-Peer Electronic Cash System. https://bitcoin.org/bit

coin.pdf

NIST National Institute of Standards and Technology (2012). NIST Special Publication
800-30 Rev. 1 – Guide for Conducting Risk Assessments. https://doi.org/10.6028/NIST.SP
.800-30r1

NIST National Institute of Standards and Technology (2017). NIST Special Publication
800-63B – Digital Identity Guidelines – Authentication and Lifecycle Management. https:
//doi.org/10.6028/NIST.SP.800-63b

NIST National Institute of Standards and Technology (2022). NIST Special Publication
800-218 – Secure Software Development Framework (SSDF) Version 1.1. https://doi.org/
10.6028/NIST.SP.800-218

Open Web Application Security Project (2021a). SQL Injection Prevention Cheat Sheet. https
://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.
html

Open Web Application Security Project. (2021b). OWASP top ten 2021. https://owasp.org/w
ww-project-top-ten/

Paar, C. & Pelzl, J. (2010). Understanding Cryptography. A Textbook for Students and Practi-
tioners. Springer.

134
PCI Security Standards Council (2022). Payment Card Industry Data Security Standard:
Requirements and Testing Procedures, v4.0. https://listings.pcisecuritystandards.org/d
ocuments/PCI-DSS-v4_0.pdf

Thales (2022). The electronic passport in 2021 and beyond. https://www.thalesgroup.com/e

n/markets/digital-identity-and-security/government/passport/electronic-passport-tre
nds

Whitten, A. & Tygar, J.D. (1999). Why Johnny Can’t Encrypt: A Usability Evaluation of PGP 5.0.
https://people.eecs.berkeley.edu/~tygar/papers/Why_Johnny_Cant_Encrypt/USENIX.
pdf

Zivadinovic, D. (2014). So funktioniert E-Mail made in Germany. (in German) https://www.

heise.de/newsticker/meldung/So-funktioniert-E-Mail-made-in-Germany-2188248.htm
l

135
 LIST OF TABLES AND
FIGURES
Figure 1: Encryption using XOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Figure 2: Agreement on key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Figure 3: Structure of the AES algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Figure 4: An elliptic curve in the plane of real numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Figure 5: Typical Structure of Cryptographic Hash Functions . . . . . . . . . . . . . . . . . . . . . . . . . 37

Figure 6: Creation of a digital signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Figure 7: Verification of a digital signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Figure 8: Creation of HMAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Table 1: Coding of three pixels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Figure 9: FIDO2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Figure 10: Sensitivity of biometric authentication and resulting error rates . . . . . . . . . . . . 63

Figure 11: Sequence diagram: Kerberos authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Figure 12: Sequence diagram: Third-party cookies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Figure 13: Cookie properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Figure 14: Basic setup of a firewall system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Figure 15: Structure of a Demilitarized Zone (DMZ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Table 2: Reference Models for Network Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Figure 16: Encapsulation of data in TLC/IP communication . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Figure 17: Security mechanisms in the layer model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Figure 18: SSL in the network layer model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

136
Figure 19: Message protection using TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Figure 20: Message protection using IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Figure 21: IPSec Application Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Figure 22: IPSec Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Figure 23: Security of IPSec in transport mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Figure 24: Security of IPSec in tunnel mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Figure 25: Authentication in GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Figure 26: Mail path from sender to receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Figure 27: Basic structure of a blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

137
IU Internationale Hochschule GmbH
IU International University of Applied Sciences
Juri-Gagarin-Ring 152
D-99084 Erfurt

Mailing Address
Albert-Proeller-Straße 15-19
D-86675 Buchdorf

[email protected]
www.iu.org

Help & Contacts (FAQ)

On myCampus you can always find answers
to questions concerning your studies.