Computer security (EITA25) - Report for Project 2

Joel Hogeman Michael Young

Lunds Tekniska Högskola Lunds Tekniska Högskola
Lund, Sweden Lund, Sweden
dat15jho@student.lu.se mi3236yo-s@student.lu.se

Hannes Lundh Dennis Phan

Lunds Tekniska Högskola Lunds Tekniska Högskola
Lund, Sweden Lund, Sweden
dat15hlu@student.lu.se de4410ph-s@student.lu.se

March 6, 2019

1
1 Architectural overview
1.1 Overview of model
The program mainly consists of a client and a server exchanging information
between one another, by using different components to access information
they need. An overview of the model can be seen in figure 1. The client and
the server initially sets up a secure connection through TLS, Transport Layer
Security, and thereafter uses this connection to safely exchange information.
Once the connection is up, the client and server authenticates each other
by using certificates that are stored in their own separate keystores and
truststores, more about how these work can be read in 1.2.
In order to handle several instances, the server can keep track of several
users at once. This enables several clients to be connected to the server
at the same time, without the server having to disconnect a user when a
new client wants to connect to the server. If the client was successfully
authenticated in the previous steps, the user can access the database which
is stored in the server-side. The information that the user is able to access
in the database is based on the authority level of the user. To validate if
a user has the required authority to access a certain piece of information,
a mix of a role-based and attribute-based access control is used. How the
access control works can be read in 1.3.

Figure 1: Model of the program

2
1.2 Keystores and truststores
As one of the factors in the two factor authorization used is certificates,
keystores and truststores are used to store the different certificates. Certifi-
cates are a way to show that you are who you say you are. Certificates have
different hierarchies, where one or more are trusted certificates that are used
to sign certificates that are not trusted in order for them to be trusted. If
there were no hierarchies there would be no trusted certificates and the sign
chain would never end.
In the program the trusted certificate, certificate authority (CA), is
stored in both the servers and the clients truststore. Each user has their
own keystore, that is because the class KeyManagerFactory only takes one
password per keystore[5]. So in order for the users certificates to each have
their users password to access, there has to be one keystore per user. All user
certificates are signed by the CA and when you sign in to the program the
server checks to see that the certificate is signed correctly, by using the CA
in its truststore. The client does the same check for the server certificate.

1.3 Access control

The access control mechanism of the server makes use of role-based as well
as attribute-based access control. Each user account that can log in to the
client application has a role of either doctor, nurse, patient or government
assigned to it. Whether authorization for some action in the database will
be granted or not is in part decided upon based on the role of the user asking
for authorization. Only a doctor for example, is authorized to create a new
patient record.
The attribute-based part of the mechanism takes into account both sub-
ject and object attributes. Doctors and nurses has as subject attributes the
divisions they belong to and the patients they are treating. A record has
as object attributes the relevant division as well as the assigned doctor and
nurse. For some actions, only a certain combination of role and attributes
will lead to an access control decision granting authorization. Which com-
binations of roles and attributes that will lead to what decisions is decided
by rules that are programmed into the system. Doctors and nurses can for
example only read records associated with their division. How this is actu-
ally implemented is through a single class called AccessControl, which has
function for each type of access, for example allowedRead, allowedWrite, etc.
Each method in the database has to call these respective functions before
continuing.

3
2 Ethical discussion
2.1 Ethical responsibilities as an engineer
The system that the hospital administration has requested has a focus on
confidentiality. In reality though, availability could be seen as more impor-
tant. Consider the situation where a patient needs to temporarily trans-
fer to another hospital for treatment. Accessing the records from another
place could take time, which in turn could prove to be valuable time for
the patients. In addition, many situations at hospitals have life and death
consequences and doctors may in those situations require immediate access
to a medical journal in question. If the system would be down during this
critical time, the patient may lose their life. Up-time may also not be the
only factor to take into consideration when analyzing the availability. A
doctor may in some circumstances require access to records of patients that
he does not officially treat, such as in an emergency situation.
One might then ask if the engineers who are implementing the system
have an ethical responsibility to consider such circumstances, or if they are
to just implement the requested functionality. Some might argue that the
engineers do not have this kind of responsibility, as it is the hospital ad-
ministration who knows the most about the hospital’s requirements and is
ultimately in charge of running the hospital and its systems. We would
however personally argue that the engineers do have such a responsibility.
In our view it is only the engineers who have the kind of security perspec-
tive to be able to think about some of these of issues, and those in charge
of the hospital cannot be expected to have such expertise. The engineers
have an ethical responsibility to at least consider these issues thoroughly
when implementing the system, and at the very least raise these issues and
start a discussion with the hospital administration about any potential gaps
in the security model. We also believe that all individuals are ultimately
responsible for their own actions and it is not ethically right to simply pass
the blame of any potential negative consequences on to someone else when
you had every opportunity to prevent such consequences. Based on this
conclusion, one might go so far as to say that the engineers have an ethical
responsibility to not deliver the requested implementation if the hospital
administration were to ignore the raised potential security and availability
threats.

2.2 Access control

An ideal access control scheme of a hospital should be implemented in such
a way as to make use of a proper balance between confidentiality, integrity
and availability. Patient records should be able to be granted access for
reading and writing only when necessary according to the principle of least
authority. However when dealing with people’s health it’s also important

4
that records are available when they should be, so a trade-off is needed. The
doctor that created the record and also the assigned nurse should obviously
be able to read and write in the record since that might be necessary when
treating the patient. The patient should also be able to read the record since
he or she should have the right to read information concerning his or her
health. In the implemented access control all of the above confidentiality
and integrity requirements are met, with authorization for reading also being
given to the government and the staff members of the same division. The
government is also able to delete records, which is a double edged privilege
since it might be an important one for national security but could also be
potentially misused. A bigger issue with the implementation is that if a
patient meets a new doctor from another division, that doctor is currently
not able to read all of the patients records which he or she arguably should
be able to do.

3 Security evaluation
3.1 Two-factor Authentication
The system currently uses a two-factor authentication where access to a
keystore containing a certificate signed by a CA, as well as the password to
the keystore is needed. By using this type of authentication, the security of
the system is higher when comparing to only using a password. Since every
user uses their own separate certificate stored in their own keystore, having
access to a user’s keystore would cause no harm without the password to
that keystore. In the same way, knowing a user’s password would not be
harmful if the attacker doesn’t have access to the keystore. In addition,
this also means that a potential attacker cannot simply create their own
keystore and try to authenticate to the server with it. Even though the
attacker technichally would have access to a keystore as well as a password,
without a certificate signed by the trusted CA, the authentication would
fail.

3.2 Replay attack

A replay attack is when a third party adversary captures a user response
from an eavesdropped network connection and re-transmits it[7].
To guard against replay-attacks the communication between client and
server is established using the TLS-protocol. Messages sent with TLS uses
MAC and sequence numbers to ensure that isolated captures aren’t possible
to replay. That is however not enough protection since if there is eavesdrop-
ping also during the handshake phase, the whole TLS-connection would be
possible to replay. Therefore, in a TLS-handshake, a nonce is sent by both
client and server.

5
 The nonce consists of a random number and a timestamp. The point of
this is that a server never allows an already received nonce to be reused. If
an adversary captures a complete TLS-connection, including the handshake
with the nonce, and tries to replay it, it will not work because the nonce is
the same as the one from the earlier exchange.

3.3 Man-in-the-middle attack

A man-in-the-middle attack is an attack where the attacker intercepts the
communication between two parties and possibly alters the messages and
makes the parties believe that they are directly communicating with each
other[7].
The potential threat of a man-in-the-middle attack would be a third-
party program intercepting the connection and making the client believe
that they are connected to the correct server, when it actually isn’t, as well
as making the server believe that an invalid client trying to connect is valid.
In the program, as mentioned before, the client and the server authenticates
each other’s certificates once a connection has been set up before they start
to exchange information. Since both sides are checking if the certificate
received is signed by the certificate authority in their respective truststores,
they can confirm whether the other party is trusted or not. Only if the other
party is trusted, will they start exchanging information. Because of this
authentication, a third-party program cannot intercept the communication
without being signed by the proper certificate authority and therefore a
man-in-the-middle attack is not possible.

3.4 Brute-force attack

A brute-force attack is an attack where the attacker submit many passwords
until the password is hopefully guessed correctly. There are several types
of brute-force attacks, the thing that differentiate the types are the ways in
which you ”guess” the password. For example there are exhaustive searches
where you check every variation that can be used, then there are dictionary
searches where the attacker uses a file with words, passwords or names etc.
and then mutates them in some ways. One of the smarter ways is to use
time-memory tradeoff attack where one uses generated tables in order to
guess the password.
The ways in which a brute-force attack could be a threat are if someone
could send numerous attempts to the server or keystore without any blocks
or timeouts. For attacks on the server the program does not allow for several
failed attempts, when you have failed 5 times the account gets locked and
has to be unlocked before the user can login again. However, this would
affect the availability of the program and in cases of emergency, a doctor
accidentally getting locked out could prove to be fatal. In the case for time-

6
memory tradeoff attacks a salt is used on the passwords to prevent previously
generated tables being used. The protection against brute-force attacks on
the keystores is that the attacker needs to be on the actual computer that
contains the keystores.

3.5 Cipher Suite

In the current implementation of our program with the certificates we have
generated so far, the program by default selects the cipher suite
”TLS DHE DSS WITH AES 256 CBC SHA256 ” .
This identifier can be read as follows:

1. TLS represents the protocol used.

2. DHE stands for Diffie-Hellman ephemeral and is the key exchange

algorithm used. This algorithm gives perfect forward secrecy.

3. DSS stands for Digital Signature Standard and specifies the digital
signature algorithm used in the certificates.

4. AES 256 CBC is the block cipher being used to encrypt the messages
sent through the connection. AES is the cipher itself, 256 is the key
length in bits, and CBC stands for Cipher Block Chaining and is the
mode of operation being used.

5. SHA256 is the message authentication algorithm used to guarantee

that messages have not been tampered with.

The selection of this cipher suite is currently done automatically by the

SunJSSE Provider for JSSE (Java Secure Socket Extension). The order of
preference for the available cipher suites for Java 8 can be found in the
documentation [2]. As can be seen in the documentation, the SunJSSE
Provider has many cipher suites enabled by default. Some of these rely on
old and broken cryptographic technologies, such as RC4 and should not be
used [6]. The question of which cipher suite to use and whether Oracle has
done a good job of ordering the list of enabled cipher suites based on security
is however difficult to answer. For the digital signature algorithm there are
three alternatives in the SunJSSE Provider’s list of enabled cipher suites:
DSS, RSA, and ECDSA. Our current certificates use DSS (the DSA digital
signature algorithm), which is considered as secure as RSA[3]. RSA has been
the standard algorithm used for a long time, but in recent years ECDSA has
started becoming a popular alternative with many large companies such as
Google and Cloudflare endorsing its use [8]. This is mainly due to the
fact that ECDSA is a lot faster for the same level of security and uses
smaller keys, which reduces storage and transmission requirements[4]. There

7
is however a downside to DSA and ECDSA, which is that they rely on a
random unique value for each signature with the same private key. This
leads to problems if the random number generator used is not sufficiently
random. This vulnerability has been found in many systems already. For
example, a bug in Java’s SecureRandom class led to it sometimes generating
collisions [1].

References
[1] Richard Chirgwin. Android bug batters Bitcoin wallets. Aug. 2013. url:
https : / / www . theregister . co . uk / 2013 / 08 / 12 / android _ bug _
batters_bitcoin_wallets/.
[2] Java Cryptography Architecture Oracle Providers Documentation for
JDK 8. url: https://docs.oracle.com/javase/8/docs/technotes/
guides/security/SunProviders.html#SunJSSEProvider.
[3] Amrita Mitra. DSA vs. RSA. Visited: 2019-02-24. url: https://www.
thesecuritybuddy.com/encryption/dsa-vs-rsa/.
[4] Nick Naziridis. Comparing ECDSA vs RSA. Visited: 2019-02-21. url:
https://www.ssl.com/article/comparing-ecdsa-vs-rsa/.
[5] Oracle. Java Secure Socket Extension (JSSE) Reference Guide. Vis-
ited: 2019-02-21. url: https://docs.oracle.com/javase/8/docs/
technotes/guides/security/jsse/JSSERefGuide.html.
[6] Prohibiting RC4 Cipher Suites. url: https://tools.ietf.org/html/
rfc7465.
[7] William Stallings and Lawrie Brown. Computer Security: Principles
and Practice. Pearson, 2018.
[8] Nick Sullivan. ECDSA: The digital signature algorithm of a better in-
ternet. Aug. 2018. url: https://blog.cloudflare.com/ecdsa-the-
digital-signature-algorithm-of-a-better-internet/.

8
 EITA25 peer-review of group 23

group 21

March 2019

So first off I will start with the minor problems. There are some minor things like the fact that Michael
Young forgot to write his email on the front page and that there are some inconsistencies with how the
references are placed in the text, sometimes before the dot and sometimes after.
As for the more major things, there are positives and negatives which I will categorize per chapter of the
report.
Architectural Overview: Here you don’t bring up any data flow, and in part 1.2 there are thing which
might be confusing for the target audience (someone who has not taken the course), for example in the
last sentence where “public key” is pulled out of thin air and should have been better explained. The rest
of this section is however well written and appropriate for the target audience. You also use references
here which is good.
Ethical Discussion: You don’t mention much about the end-users such as hospital staff and patients.
What could their ethical responsibilities be? Also what do the relevant laws say about the points made in
the discussion? Other than that you bring up a lot of good points and it was interesting to read.
Security Evaluation: The security evaluation is well written and quite thorough. Cipher suite feels
like an odd section perhaps but not much else to complain about. Again you use references which is
good.

1
 Peer review
ol4084da-s, mat14fsu
March 2019

The functionality is well described and is easy to understand. One thing

that could be added is how the Access Control does the check for what role and
attribute the user has. Is it stored as string-values on the object and looping
through all cases? That is the only thing missing from functionality from what
I can see.
In the access control you take up a weakness in your system: a new doctor
to a patient is unable to read all the history of that patient. Here you could
as well add an example of how you could fix this issue. Here you also tell the
reader that the government could misuse the ability to delete records. It could
be of interest here as well to add an example of how to prevent this in a future
design of the security system.
You state that a user gets locked out after 5 failed attempts to login on the
server. This does not seem like a safe way to handle doctors access in case of
an emergency. I guess the motivation is to prevent against brute-force attacks
but maybe there are better ways to protect against that. Should at least add
something about the weakness of being able to get locked out as a doctor.
You do not mention how the access to the keystores will be limited. For
example: will the users carry them with them on physical devices or will they
be avaliable on all hospital computers?
Maybe an overview of the whole authentification process could be provided
before you go into details.

1
4 Improvement Sheet
• Added email for Michael, as pointed out in group 21’s review.

• Added a description of how our access control scheme is actually im-

plemented, as pointed out in group 24’s review.

• Fixed inconsistencies with placement of references.

• Added a potential consequence of locking accounts with several failed

login attempts, which was pointed out in group 24’s review.

• Removed unexplained mention of public key in Architecture section,

as pointed out by group 21’s review.

11