Conference PaperPDF Available


Finding a robust security mechanism for audit trail logging has long been a poorly satisfied goal. There are many reasons for this. The most significant of these is that the audit trail is a highly sought after goal of attackers to ensure that they do not get caught. Thus they have an incredibly strong incentive to prevent companies from succeeding in this worthy aim. Regulation, such as the European Union General Data Protection Regulation, has brought a strong incentive for companies to achieve success in this area due to the punitive level of fines that can now be levied in the event of a successful breach by an attacker. We seek to resolve this issue through the use of an encrypted audit trail process that saves encrypted records to a true immutable database, which can ensure audit trail records are permanently retained in encrypted form, with no possibility of the records being compromised. This ensures compliance with the General Data Protection Regulation can be achieved.
A Secure and Privacy-Friendly Logging Scheme
Andreas Aßmuth1, Robert Duncan3, Simon Liebl1,2, and Matthias S ¨
1Technical University of Applied Sciences OTH Amberg-Weiden
Amberg, Germany
Email: {a.assmuth |s.liebl |m.soellner}
2PhD Student at Abertay University, Dundee, UK
3University of Aberdeen
Aberdeen, United Kingdom
Abstract—Finding a robust security mechanism for audit trail
logging has long been a poorly satisfied goal. There are many
reasons for this. The most significant of these is that the audit trail
is a highly sought after goal of attackers to ensure that they do
not get caught. Thus they have an incredibly strong incentive
to prevent companies from succeeding in this worthy aim.
Regulation, such as the European Union General Data Protection
Regulation, has brought a strong incentive for companies to
achieve success in this area due to the punitive level of fines
that can now be levied in the event of a successful breach by
an attacker. We seek to resolve this issue through the use of an
encrypted audit trail process that saves encrypted records to a
true immutable database, which can ensure audit trail records
are permanently retained in encrypted form, with no possibility
of the records being compromised. This ensures compliance with
the General Data Protection Regulation can be achieved.
Index Termslogging; audit trail; cryptography; privacy; secu-
Today, we all are used to authenticate ourselves in order
to access systems and services we use in our everyday life.
Authentication can be viewed from two different perspectives.
For ourselves and especially for our private use, authentication
ensures that no one else can access our data. For the system or
service provider, authentication is used to distinguish between
users. Different users may have different subscriptions for
the services and, for example, the service provider is not
interested in users using services for free that should be paid
for. Additionally, the system provider might get contacted by
authorities or law enforcement agencies if illegal actions have
occurred involving their services. In this case, authentication
is used to determine which user is responsible for the illegal
actions and which users were not involved at all.
At work, it is common practice that several employees share
a computer or work with one industrial machine. And of
course, Cloud-based services and applications allow multiple
employees to work on a project collaboratively. In all these
systems, it is important to identify and authenticate the current
user in order to grant him or her the appropriate privileges.
In order to trace who, for example, has processed an order,
the digital identity of the employee is saved and logged. In
the event of a severe mistake, a negligent operation on an
expensive machine or illegal actions, the company wants to
ensure to be able to track down the responsible employee.
And if we additionally take compliance to security and pri-
vacy regulations into account, we must consider so called
malicious insider actions as well. These are incidents that
were deliberately caused by (former) employees who want
to stain the companies reputation or damage the company’s
equipment. According to a study by the Ponemon Institute,
more than 70 % of participating companies have had more
than ten insider-related incidents within a year [1].
Features and services that are used to track individual
actions to single employees can be viewed critically because
such measures can violate the privacy of employees. One
such example is the so called “productivity score” [2], which
has raised much criticism and was condemned by the press
as a means for workplace surveillance [3] [4]. But even
without such services, permanent monitoring employees may
be used to assess their productivity. Therefore, especially
companies with a strong workers’ council are looking for
other solutions. Finding such solutions is often also in the
company’s executive’s interest because some companies have
been fined in recent years for violations of the General Data
Protection Regulation (GDPR). For example, in 2020, the
Hamburg Commissioner for Data Protection and Freedom of
Information fined H & M (Hennes & Mauritz) C 35.3 million
for data protection violations of employees’ personal data.
The company recorded a considerable amount of highly per-
sonal data about their employees’ vacation experiences, but
also symptoms of illness and diagnoses. In addition, some
supervisors acquired a broad knowledge of their employees’
private lives through personal and floor talks, ranging from
rather harmless details to family issues and religious beliefs.
Some of this knowledge was recorded, digitally stored and
partly readable by up to 50 other managers throughout the
company. The recordings were sometimes made with a high
level of detail and recorded over greater periods of time
documenting the development of these issues. This practice
8Copyright (c) IARIA, 2021. ISBN: 978-1-61208-845-7
CLOUD COMPUTING 2021 : The Twelfth International Conference on Cloud Computing, GRIDs, and Virtualization
only came to light when the data became accessible company
wide following a misconfiguration error, following which the
regulator became involved [5].
Finding a solution to this problem, to be capable of tracking
down individuals without violating their privacy, is not trivial.
Going back to shady practices some companies used before
they discovered the necessity of being able to track down
an employees actions if needed, is definitely no suitable
solution. Imagine a manufacturing company assigns a group
of employees to machine. This would allow to assess the
whole team, but would not violate the privacy of individual
employees. But in case of mistakes, illegal actions, etc.,
the company then would not be capable of tracking down
the responsible employee. In practice, this approach leads to
additional drawbacks concerning security. In order to facilitate
work, in this approach such groups of employees very often
use only a single, usually rather weak password that is easy
to remember (or may even be found on a sticker right at
the machine) instead of having strong individual passwords.
In case of sabotage by an employee, the responsible person
cannot be determined because he or she does not even have
to belong to that group of employees.
This paper is structured as follows: in Section II, we
describe possible logging strategies before we address security
and privacy challenges in Section III. In Section IV, we present
our solution for a secure and privacy-friendly logging scheme
and further ideas, how our solution can be modified in order
to fulfil special or additional requirements. We conclude in
Section V with an outlook on future work.
Logging is usually carried out for the purpose of providing
an audit trail of all activities involved in running the system.
This is a practice that has long been carried out in the
accounting profession to ensure a robust mechanism exists
such that in the event of a disaster, the audit trail may be
used to restore the accounting records in order to reconstitute
the accounts of the organisation. Of course, once logging for
this purpose started to be carried out in electronic systems,
smart attackers realised that due to inherent weaknesses in
database systems, by attacking the audit trail, it was possible to
remove evidence of their incursion into the system by deleting
or modifying the audit trail records.
While a number of early database systems offered an
immutable database option, there were a number of challenges
that needed to be overcome. First, the immutable database
could not use key fields, meaning retrieval or analysis of
the contents of the database would be both cumbersome and
slow. Second, and perhaps more importantly, there was nothing
to prevent the entire database from being deleted once the
attacker gained entry and has escalated sufficient privileges.
This meant that the use of traditional database systems
would not be sufficient to achieve our requirements to retain a
secure audit trail through logging. This brought about the need
to find an alternative immutable database solution instead. One
option would have been to use blockchain, which provides the
core security for crypto-currencies. However, there is a poten-
tial significant overhead in going down this route. The public
blockchain relies on thousands of nodes, which are required
to perform extensive cryptographic algorithmic computations
to ensure a proper consensus of the contents of the blockchain
can be guaranteed, but this brings a huge overhead to the
equation, since those who perform the cryptographic tasks are
looking for a reward for the considerable efforts they provide,
meaning considerable extra costs of operation, along with a
lesser level of performance due to the huge redundancy on
The alternative solution here would be for the corporate to
use a private blockchain, but this also brings challenges. This
private blockchain would be provisioned by the corporate, but
now their challenge would be to find a balance between choos-
ing the minimal level of blockchain redundancy to improve
latency, against being able to retain a sufficient number of
nodes securely enough to retain full control over the contents
of the blockchain.
However, in 2020, a new start company introduced im-
mudb [6], a lightweight, high-speed immutable database that
is specifically designed to complement existing transactional
database systems. It is tailor made to track changes in the main
database system and to then record these transactions, or logs,
in the tamperproof immudb. The immudb system gives you
the same cryptographic verification of the integrity of data
written with SHA-256 like classic blockchain without the cost
and complexity associated with blockchains today. This means
that unlike traditional transaction logs, which are very hard to
scale, immudb is extremely fast, scalable, robust and open
source, making it ideal to incorporate for this purpose. For
further details on the immutable storage we refer to [7].
Security and privacy challenges in this area are not new. In
1999, Schneier and Kelsey [8] set out to secure the collection
of sensitive logs using encryption, to ensure that forensic
records could be maintained in the event of a cyber breach.
Some five years later, Waters et al. [9], realised that system
logs were becoming a prime attack vector for attackers, who
were seeking to cover their trail after successfully break-
ing in to computer systems. The authors felt that improved
searchability would be an asset in dealing with a subsequent
forensic examination, and they sought to provide a rapid search
function to interrogate this encrypted data. Further, they im-
plemented an audit log for database queries using hash chains
for integrity protection and identity-based encryption with
extracted keywords to enable better searching. Over a decade
later, Syta et al. [10], felt that such was the interest of attackers
in this area that further strengthening of systems would be
necessary to ensure proper protection could be achieved. The
authors attempted to allow a considerable increase in scale, as
well as the development of multi-signatures to provide further
protection. Their system is claimed to protect against man-in-
the-middle attacks.
9Copyright (c) IARIA, 2021. ISBN: 978-1-61208-845-7
CLOUD COMPUTING 2021 : The Twelfth International Conference on Cloud Computing, GRIDs, and Virtualization
The logging scheme we propose consists of two basic
components: (a) an appropriate secret sharing scheme and
(b) an immutable storage. Readers who are already familiar
with immutable storage and secret sharing schemes may want
to skip the according subsections.
A. Immutable Storage
The reason we seek to use immutable storage is to ensure
that we can only ever add new records to the database. We are
not ever allowed to modify or delete records. This will allow
us to create entries of permanent record with which to store
any information related to the authentication of employees.
This will prevent any party from interfering with any entry of
permanent record, ensuring we are able to retain permanency
of all such transactions. This will provide an audit trail of
all transactions relating to employees. Regardless of whether
any attack comes from an external source, or from a malicious
inside party, they will not be able to alter any of these records.
The data that is stored in this immutable storage is encrypted
in order to fulfil the demanded privacy constraints. Since is
not possible to tamper with the data stored in this immutable
storage, even gaining access to the data will not reveal any
interesting details to the attacker.
B. Secret Sharing
The idea of secret sharing is as follows: some data Dis
divided into npieces, D1, . . . , Dn, in such a way that Dcan
be reconstructed of any k < n pieces Di. Additionally, it is
ensured that the knowledge of k1or less pieces Diis not
sufficient to reconstruct D. In this case, the reconstruction ends
up with a completely undetermined set of bits. Adi Shamir
proposed a secret sharing scheme in 1979 that is based upon
polynomial interpolation [11]. To emphasise the importance
of the two integers nand k, Shamir named such a secret shar-
ing scheme a “(k, n)threshold scheme”. Following Shamir’s
blueprint, Dis associated with an integer smaller than some
prime number p>D. For kpoints (xi, yi)GF(p)×GF(p),
i= 1, . . . , k, with distinct coordinates xi, there exists one and
only one polynomial qof degree k1, such that q(xi) = yi
holds for all i= 1, . . . , k. For the polynomial
q(x) =
the coefficients a1to ak1are chosen randomly and the
coefficient a0is used to store D, so a0=D. In order to
obtain the ndifferent pieces D1, . . . , Dn, the function values
of the indices are computed:
Di=q(i), i = 1, . . . , n.
From any subset of kelements Di, the coefficients aican be
computed, provided that their identifying indices are known.
After the polynomial qhas been revealed, the reconstruction
of the data Dis achieved by computing q(0) = a0=D.
If Shamir’s secret sharing scheme is intended to be used, the
first step is to specify k, the number of pieces needed for
the reconstruction of D. The total number of pieces then is
n= 2k1. As pointed out before,
k=n+ 1
or more pieces Diallow the reconstruction of D, whereas less
than k,
k1 = jn
are not sufficient.
Blakley’s solution to the secret sharing problem is based on
finite geometry [12]. He suggested to encode the secret as a
coordinate of a point in a k-dimensional space. The basic idea
of Blakley’s secret sharing scheme is that any knonparallel
(k1)-dimensional hyperplanes intersect at a specific point
which in this case contains the secret. In order to generate
the secret shares, nhyperplane equations are computed using
the intersection coordinates and additional random numbers
modulo a prime number p. Any kor more out of these n
hyperplane equations may be used to construct a system of
linear equations that can easily be solved in order to obtain the
secret provided that the determinant of the coefficient matrix
formed of the given hyperplane equations is nonzero modulo p.
For these two traditional secret sharing schemes, the shares
are at least of the same size as the secret itself. The authors
of this paper have successfully used secret sharing schemes
before, e.g., in order to store log files of the nodes of a Cloud
system in a decentralised way [13]–[15]. For applications like
this, that require secret sharing schemes to be applied to large
amounts of data, this is probably unfavourable. In this case,
the work of Krawczyk should be helpful who found out that
if the notion of secrecy is reduced to computational instead of
information theoretic secrecy, a remarkable amount of space
and communication can be reduced [16]. But as the next
subsection is going to clarify, this is not a problem for the
proposed logging scheme, because the secret sharing scheme
is used to secure only a small amount of data, namely the
private key of a public key encryption scheme.
C. Proposed Logging Scheme
On the basis of the two core components, immutable storage
and secret sharing, we describe our solution to the problem
in this subsection. Our solution can be applied to a single
company site, but also to multiple sites of a (larger) company,
which are located in different countries and interconnected
using a Cloud service.
To achieve maximum security, all persons must authen-
ticate themselves using individual accounts on the system.
Preferably, two-factor authentication should be used. The
information, who logged into the system at which time, must
be stored encrypted in order to prevent unauthorised personnel
from reading this sensitive information. Since we have a
system for a whole company in mind, it seems plausible to
assume there are several computers or machines that all need
to be in the logging system because employees log into all of
10Copyright (c) IARIA, 2021. ISBN: 978-1-61208-845-7
CLOUD COMPUTING 2021 : The Twelfth International Conference on Cloud Computing, GRIDs, and Virtualization
these computers and machines. All of these devices must be
capable of encrypting their logging information and, therefore,
need an encryption key to be stored on each device. For our
logging system, we choose a public-key encryption scheme,
so the encryption key may be stored on all of these devices
and is assumed to be publicly known. An encryption scheme
with symmetric keys that uses the same key for encryption
and decryption is not suitable in this case because of the
necessity to have the encryption key stored on a large number
of devices. This secret key might fall into the hands of an
unauthorised person, e.g., from a single unsecured computer,
and this person would then also be capable of reading all the
sensitive logging information. Thus, in order to be able to
read the sensitive information, the corresponding private key
is required for decryption. This key is not stored on these
computers and machines because there is no need to decrypt
the data locally. The private key is divided into a number of
parts, e.g., into three parts: one part for the employer, one part
for the workers’ council representing the employees and one
part for law enforcement authorities. It might be sensible to
have more or other groups, therefore, we do not stick to this
example but just count these different groups, which all get
a part of the secret key. It must be stressed that all of these
parts are needed to reconstruct the private key in order to
decrypt the encrypted logging data. So all of the groups must
agree and combine their private key parts (AND operation).
Figure 1 depicts the fragmentation of the private key and the
Logging System public key (encryption)
private key (decryption)
& &
Group 1 Group 2 Group 3
Secret Sharing:
split the shared
Secret Sharing:
split the shared
Secret Sharing:
split the shared
Figure 1. Distribution of the private key among several groups and persons.
distribution of the parts to three groups. In practice, these
parts of the private key would possibly be in possession of
one person of the respective group. But this would be quite
unfavourable because this makes that single person a high-
value target for attacks that aim to get the respective part of
the secret key. Additionally, if there is an incident, it must
be dealt with instantly. It would be unacceptable if that one
person would then be in another shift, ill at home or on leave.
That one person might also be threatened or bribed to give
access to his or her part of the secret key; or that person
might accidentally loose or delete their part of the private key.
For all these reasons, it makes sense to divide the secret key
part of each group into pieces using a secret sharing scheme.
These pieces are then given to npersons of each group and
it takes kof them to agree in order to merge the private key
part of the group.
To sum up, this logging system supports both: security and
privacy. Employees use their strong individual credentials for
authentication. But they must not fear workplace surveillance
or an unauthorised assessment of their productivity because
their employer is not capable of reading the log files arbitrarily.
In case an incident occurs and there is an official investigation,
the different groups combine their parts to reconstruct the
private key for the decryption of the log files. For each group,
access to the respective part of the secret key is granted if a
majority of group members (kout of n) agree.
D. Adaptability to Certain Scenarios
The presented scheme proposes that the different groups
have to combine their parts of the private key to get the full
private key and gain access. As the parts of the private key
are combined with an AND operation, all groups have to
contribute to gain access. On the other side scenarios might be
interesting and desirable, where it would be sufficient when
only jout of mgroups come together to combine their keys in
order to access the data. For this purpose the logging scheme
can be adapted to share the private key among the groups also
with the same secret sharing principle and inside a group the
shared part can be shared with this scheme as proposed above
(cf. Figure 2).
Logging System public key (encryption)
private key (decryption)
Secret Sharing:
split the private key (j;m)
Group 1 Group 2 Group 3
Secret Sharing:
split the shared
secret (k2;n2)
Secret Sharing:
split the shared
secret (k1;n1)
Secret Sharing:
split the shared
secret (k3;n3)
Figure 2. Adaption of the system: Secret Sharing among groups.
By using this adapted scheme it is possible to gain access to
the secret, if only jout of mgroups come together to combine
11Copyright (c) IARIA, 2021. ISBN: 978-1-61208-845-7
CLOUD COMPUTING 2021 : The Twelfth International Conference on Cloud Computing, GRIDs, and Virtualization
the private key and in every group it would take only kout
of nmembers of this group to agree to reconstruct their part
of the shared secret. As it is only a matter of design, how
many group members are needed to reconstruct their partial
secret, the scheme can be adapted very flexibly to different
scenarios: Each group gcan have its own kgand ng. So, for
example, group 1 has size n1and k1members of this group
have to agree, group 2 may be much larger (n2> n1) but
fewer members (k2) are needed in order to reconstruct their
group’s part of the secret key, and so on.
Logging System public key (encryption)
private key (decryption)
Secret Sharing:
split the private key (j;m1)
Necessary Group 1 Group 2 Group 3
Secret Sharing:
split the shared
secret (k2;n2)
Secret Sharing:
split the shared
secret (k1;n1)
Secret Sharing:
split the shared
secret (k3;n3)
Figure 3. Further adaption of the system: Secret Sharing among groups and
making one group necessary.
Furthermore, it is also possible to include one or more
groups, which have to contribute necessarily (e.g., group 1 in
Figure 3), because it is possible to combine AND operation
and secret sharing on the group level, too. This means the
private key is first split in two (or more to include more
necessary groups) parts, which have to be combined again with
AND operation later. One of this parts can then be distributed
with secret sharing, the other parts are only shared within the
necessary groups.
As a first step, we have developed a highly secure logging
approach for logging events connected with employees within
the organisation. The logging data is captured and fully
encrypted to ensure full compliance with the GDPR for any
PII relating to employees of the organisation, since the data
cannot be identified by anyone other than the duly authorised
users of the system. We have demonstrated that this approach
can deliver exactly the high security level of employee privacy
which we were seeking.
Our next step will be to plan for the implementation of a
proof-of-concept solution. As part of this process, we would
test the outcome and performance of the system using differing
secret sharing schemes to ensure we can deliver the most
effective and powerful solution. However, we would also
consider the possibility of investigating the development of
how a verifiable secret sharing solution might further improve
our suggested scheme.
Once we have reached that stage, we would seek to carry out
an investigation into possible practical issues and endeavour to
recognise any remaining problems with this work. We consider
there may be the possibility of a collaboration between the
two universities, OTH Amberg-Weiden and the University of
[1] Ponemon Institute, Ed., “2018 Cost of Insider Threats: Global”,
April 2018, [Online]. Available: https://153j3ttjub71nfe89mc7r5gb-
Insider-Threat-Global-Report-FINAL.pdf [accessed: 2021-04-01]
[2] Microsoft, Ed., “Microsoft Productivity Score”, [Online]. Available: [accessed: 2021-04-
[3] A. Hern, “Microsoft productivity score feature criticised as
workplace surveillance”, The Guardian, [Online]. Available:
productivity-score-feature-criticised-workplace-surveillance, 2020-11-26
[accessed: 2021-04-01]
[4] S. Hurtz, “Angestellte ¨
uberwachen? Microsoft macht’s m¨
uddeutsche Zeitung, [Online]. Available:, 2020-
11-27 [accessed: 2021-04-01]
[5] Hamburg Commissioner, Ed., “35.3 Million Euro Fine for Data Pro-
tection Violations in H&M’s Service Center”, Datenschutz-Hamburg
GDPR fine for GDPR employee data breach, Press Release, 2020.
[Online]. Available:
01-press-release-h+m-fine.pdf [accessed: 2021-04-01]
[6] D. Zimmer, “immudb”, 2021, [Online]. Available: [accessed: 2021-03-
[7] M. Paik, J. Iraz´
abal, D. Zimmer, M. Meloni, and V. Padurean, “im-
mudb: A Lightweight, Performant Immutable Database”, Available: [accessed: 2021-04-
[8] B. Schneier and J. Kelsey, “Secure audit logs to support computer
forensics”, ACM Transactions on Information and System Security
(TISSEC), 2(2), pp. 159-176, 1999.
[9] B. R. Waters, D. Balfanz, G. Durfee, and D. K. Smetters, “Building an
Encrypted and Searchable Audit Log”, NDSS, 4, pp. 5-6, 2004.
[10] E. Syta et al., “Keeping authorities ’honest or bust’ with decentralized
witness cosigning”, 2016 IEEE Symposium on Security and Privacy
(SP), pp. 526-545, 2016.
[11] A. Shamir, “How to share a secret”, Communications of the ACM,
vol. 22, no. 11, pp. 612-613, 1979.
[12] G. R. Blakley, “Safeguarding cryptographic keys”, Managing Require-
ments Knowledge, International Workshop on (AFIPS), Proceedings,
pp. 313-317, 1979.
[13] G. Weir and A. Aßmuth, “Strategies for Intrusion Monitoring in Cloud
Services”, pp. 49-53, 2017.
[14] G. Weir, A. Aßmuth, and N. J¨
ager, “Forensic Recovery and Intrusion
Monitoring in the Cloud”, International Journal on Advances in Security,
vol. 11, no. 3 & 4, pp. 264-263, 2018.
[15] G. Weir, A. Aßmuth, M. Whittington, and B. Duncan, “Cloud Ac-
counting Systems, the Audit Trail, Forensics and the EU GDPR: How
Hard Can It Be?” BAFA Scottish Area Group Annual Conference 2017,
Aberdeen, 2017.
[16] H. Krawczyk, “Secret Sharing Made Short”, Advances in Cryptol-
ogy CRYPTO’ 93, Proceedings, Lecture Notes in Computer Science,
vol. 773, pp. 136-146, Springer, 1993.
12Copyright (c) IARIA, 2021. ISBN: 978-1-61208-845-7
CLOUD COMPUTING 2021 : The Twelfth International Conference on Cloud Computing, GRIDs, and Virtualization
... This makes the audit log itself a central target for attackers who want to cover their traces. It therefore requires additional security measures like integrity protection [16] and encryption [17]. ...
... Audit Trails [16], [17] An audit log facilitates traceability of SLAs, data access and context information. ...
Full-text available
While 5G networks are driving a growing number of use cases in the fields of Internet of Things (IoT) and industrial applications, the vision of the next generation of mobile communications systems already includes concepts massively transforming the way people will interact with the digital world through the network, as humans are shifting into the center of diverse network driven applications. Envisaged use cases and possibilities to provide services and resources in a distributed manner render an architectural solution for trust establishment a critical component of 6G networks. This survey provides an overview of terms and visions related to the topic of trust in general and in mobile communications systems. Requirements for an end-to-end trust building framework are derived, in order to give a starting point for the design process of a trust anchor service as a component of 6G networks.
... Logs of the smartphone-based driver monitoring system are also an important source of the information about security and privacy issues. In terms of security, logs can be used for anomaly detection or event correlation [89], while in terms of privacy, logs allow checking which actions of the user are logged and how often this process occurs [90]. Moreover, it is important to check if user credentials are anonymized or used in logs directly. ...
Full-text available
Nowadays, the whole driver monitoring system can be placed inside the vehicle driver's smartphone, which introduces new security and privacy risks to the system. Because of the nature of the modern transportation systems, the consequences of the security issues in such systems can be crucial, leading to threat to human life and health. Moreover, despite the large number of security and privacy issues discovered in smartphone applications on a daily basis, there is no general approach for their automated analysis that can work in conditions that lack data and take into account specifics of the application area. Thus, this paper describes an original approach for a security and privacy analysis of driver monitoring systems based on smartphone sensors. This analysis uses white-box testing principles and aims to help developers evaluate and improve their products. The novelty of the proposed approach lies in combining various security and privacy analysis algorithms into a single automated approach for a specific area of application. Moreover, the suggested approach is modular and extensible, takes into account specific features of smartphone-based driver monitoring systems and works in conditions of lack or inaccessibility of data. The practical significance of the approach lies in the suggestions that are provided based on the conducted analysis. Those suggestions contain detected security and privacy issues and ways of their mitigation, together with limitations of the analysis due to the absence of data. It is assumed that such an approach would help developers take into account important aspects of security and privacy, thus reducing related issues in the developed products. An experimental evaluation of the approach is conducted on a car driver monitoring use case. In addition, the advantages and disadvantages of the proposed approach as well as future work directions are indicated.
Conference Paper
Full-text available
Effective activity and event monitoring is an essential aspect of digital forensic readiness. Techniques for capturing log and other event data are familiar from conventional networked hosts and transfer directly to the Cloud context. In both contexts, a major concern is the risk that monitoring systems may be targeted and impaired by intruders seeking to conceal their illicit presence and activities. We outline an approach to intrusion monitoring that aims (i) to ensure the credibility of log data and (ii) provide a means of data sharing that supports log reconstruction in the event that one or more logging systems is maliciously impaired.
Conference Paper
Full-text available
Ahead of the introduction of the EU General Data Privacy Regulation, we consider some important unresolved issues with cloud computing, namely, the insecure cloud audit trail problem and the challenge of retaining cloud forensic evidence. Developing and enforcing good cloud security controls is an essential requirement for this is to succeed. The nature of cloud computing architecture can add additional problem layers for achieving cloud security to an already complex problem area. Traditionally, many corporates have struggled to identify when their systems have been breached, let alone understand which records have been accessed, modified, deleted or ex-filtrated from their systems. Often, there is no understanding as to who has perpetrated the breach, meaning it is difficult to quantify the risk to which they have been exposed. The GDPR seeks to improve this situation by requiring all breaches to be reported within 72 hours of an occurrence, including full identification of all records compromised, failing which the organisation could be subject to punitive levels of fines. We consider why this is such an important issue, identifying what desirable characteristics should be aimed for and propose a novel means of effectively and efficiently achieving these goals. We have identified a range of issues which need to be dealt with properly to ensure a robust level of security and privacy can be achieved. We have addressed these issues in both the context of conventional cloud based systems, as well as in regard to addressing some of the many weaknesses inherent in the internet of things. We discuss how our proposed approach may help better address these key security issues which we have identified. Index Terms Cloud security and privacy; cloud audit; cloud forensics; Internet of Things.
Full-text available
Audit logs are an important part of any secure system, and they need to be carefully designed in order to give a faithful representation of past system activity. This is especially true in the presence of adversaries who might want to tamper with the audit logs. While it is important that auditors can inspect audit logs to assess past system activity, the content of an audit log may contain sensitive information, and should therefore be protected from unauthorized parties.
As organisations move away from locally hosted computer services toward Cloud platforms, there is a corresponding need to ensure the digital forensic integrity of such instances. This need is largely motivated by the locus of responsibility and also by the associated risk of legal sanction and financial penalty. Effective monitoring of activity and events is an essential aspect of such forensic readiness. A major concern is the risk that monitoring systems may themselves be targeted and affected by intruders, thereby nullifying the prospective benefits of such internal software surveillance facilities. In this paper, we outline an approach to intrusion monitoring that aims to ensure the credibility of log data and provide a means of data sharing that supports log reconstruction in the event that one or more logging systems is maliciously impaired. In addition, we identify and describe the multi-level interpretation problem as an inherent challenge to managing forensic recovery in the Cloud. // International Journal on Advances in Security, vol 11 no 3 & 4, 2018.
Conference Paper
The secret keys of critical network authorities - such as time, name, certificate, and software update services - represent high-value targets for hackers, criminals, and spy agencies wishing to use these keys secretly to compromise other hosts. To protect authorities and their clients proactively from undetected exploits and misuse, we introduce CoSi, a scalable witness cosigning protocol ensuring that every authoritative statement is validated and publicly logged by a diverse group of witnesses before any client will accept it. A statement S collectively signed by W witnesses assures clients that S has been seen, and not immediately found erroneous, by those W observers. Even if S is compromised in a fashion not readily detectable by the witnesses, CoSi still guarantees S's exposure to public scrutiny, forcing secrecy-minded attackers to risk that the compromise will soon be detected by one of the W witnesses. Because clients can verify collective signatures efficiently without communication, CoSi protects clients' privacy, and offers the first transparency mechanism effective against persistent man-in-the-middle attackers who control a victim's Internet access, the authority's secret key, and several witnesses' secret keys. CoSi builds on existing cryptographic multisignature methods, scaling them to support thousands of witnesses via signature aggregation over efficient communication trees. A working prototype demonstrates CoSi in the context of timestamping and logging authorities, enabling groups of over 8,000 distributed witnesses to cosign authoritative statements in under two seconds.
In this paper we show how to divide data D into n pieces in such a way that D is easily reconstructable from any k pieces, but even complete knowledge of k - 1 pieces reveals absolutely no information about D. This technique enables the construction of robust key management schemes for cryptographic systems that can function securely and reliably even when misfortunes destroy half the pieces and security breaches expose all but one of the remaining pieces.
Cost of Insider Threats: Global
  • Ed Ponemon Institute
Ponemon Institute, Ed., "2018 Cost of Insider Threats: Global", April 2018, [Online]. Available: [accessed: 2021-04-01]
Microsoft Productivity Score
  • Ed Microsoft
Microsoft, Ed., "Microsoft Productivity Score", [Online]. Available: [accessed: 2021-04-01]