Surveillance Cameras

Eva María Benito Sanz [s243313], Entouina Stavroulla Karoulla [s240037],

Camilla Santoro [s232441], and Zou Yong Nan Klaassen[s230351]

Technical University of Denmark

1 Abstract spyros

The rapid expansion of surveillance cameras has raised significant privacy con-
cerns, particularly regarding unauthorized access and data misuse. This report
outlines a cryptographic system designed for RoboEye Inc. to ensure that surveil-
lance footage is securely transmitted, and stored. The proposed solution leverages
cryptographic methods, including TLS for data in transit, AES for data at rest,
and Shamir’s Secret Sharing for distributed key management, to guarantee data
confidentiality, integrity, and access control.
The report begins with an analysis of risks, categorized using the STRIDE
model, and identifies key assets vulnerable to privacy violations, tampering, and
unauthorized access. Requirements are then defined for both system functionality
and security, followed by an exploration of state-of-the-art encryption and access
control models. The design implements a flexible access structure where different
user roles must collaborate to access encrypted footage based on customizable,
context-sensitive policies.
This system’s evaluation demonstrates robust mitigations against major se-
curity risks, though future work is suggested to address residual threats like
spoofing and denial-of-service attacks.

2 Introduction Marco

Author: Zou Yong Nan Klaassen

Surveillance cameras are being used more widely, which has led to an increase
of privacy concerns. They often capture sensitive information, raising the risk of
potential violations of individual privacy. In most countries it is considered illegal
or ethically unacceptable to mass record individuals without a warrant or legal
agreement. Citizens expect their privacy to be respected, even when surveillance
is necessary for security purposes. Therefore, there is a need for a surveillance
system that protects the privacy while maintaining their functionality.
RoboEye Inc. wants to develop a system that can mitigate some of these pri-
vacy concerns. The system should enforce that the recorded surveillance footage
can only be retrieved with a warrant. The system must be flexible enough to
adhere to different countries’ legal frameworks. For instance in one framework,
2 F. Author et al.

accessing surveillance footage may require the approval of a judge, law enforce-
ment agreement, and authorization of one out of three bank directors to access
the recordings. The challenge is to design a system that supports these various
access structures involving multiple authorized stakeholders for access granting
while ensuring that unauthorized parties cannot access the sensitive data.
The project focuses on using advanced cryptographic techniques to secure
data during transmission from the camera to the database and inside the database.
The solution must be able to adapt to different legal/organizational frameworks
and guarantee only authorized users can access as specified in the specific access
structure. They can retrieve surveillance footage only from respective parts of the
database required for the situation. Therefore, different entries in the database
can have different access structures. Furthermore the system should also handle
dynamic changes in access rights such as revocation of privileges or role changes.
In the following sections the report will delve into detailed design of the cryp-
tographic system. Starting with the requirements and potential risks and threats.
Followed by the state of art, the design, security, and finally the evaluation and
analysis of the system’s effectiveness in mitigating privacy risks.

3 Risk Analysis Marco

Author: Zou Yong Nan Klaassen

The risk analysis focuses on which assets are at stake within the system by
assessing the potential risk, impact, severity, and mitigations. The analysis for
the risks follows the STRIDE model [9]. To calculate the severity of the risks a
rating of 1-5 is used assuming that the threat has occurred. See table 1 for an
overview of the threat model.

Table 1. Threat model overview

Asset Risk Impact Severity Mitigations

In transit: surveil- Information disclo- Confidentiality, pri- 5 Encryption
lance footage sure vacy violation
In transit: surveil- Tampering Integrity violation 5 Integrity
lance footage checks
In database: surveil- Information disclo- Confidentiality, pri- 5 Encryption,
lance footage sure vacy violation access control
In database: surveil- Tampering Integrity violation 5 Integrity
lance footage checks

Assets at stake Our system’s infrastructure considers as an asset:

1. Cameras
2. Servers: Where the cameras’s footage will be stored.
 Surveillance Cameras 3

3. Surveillance Footage in transit from camera to database

4. Surveillance Footage in database
5. Access Control Management: After storing footage in the database, ac-
cess given to specific data and agents is crucial.

Out of scope
– Spoofing, denial of service, and repudiation risks
– Physical attacks against cameras
– Attacks against the server and database
– Social engineering

Attacker assumptions
– The attackers can be external and internal
– The attackers’ motivation can be stealing sensitive data, invade privacy, and
data tampering.
– The attackers can be skilled hackers with access to various resources, tools,
and techniques

Mitigations
– Encryption : Encrypt the surveillance footage during transit and at rest in
the database.
– Integrity checks : Check whether the surveillance footage in the database
has been altered or persist immutability.
– Access Control Management: Only allow legitimate users to access the
surveillance footage at rest and adopt principle of least privilege.

4 Requirements Marco

Author: Entouina Stavroulla Karoulla

Requirements are the basis of any system, since they define what the system
should do and the limitations it must operate with. Requirements can be classi-
fied into two categories :

4.1 Functional Requirements

These describe the specific features and capabilities, that the system must pos-
sess in order to be functional. Our system must provide:
1. Camera integration : The ability to integrate and work with various
types of surveillance cameras, supporting different protocols, resolutions, and
frame rates.
4 F. Author et al.

2. Data Capture and Transmission : The capability to capture video footage

from the cameras and also be able to transmit it to the database.
3. Data Storage : A scalable database solution to store the surveillance data,
along with efficient retrieval mechanisms.
4. Access Control Management: Functionality that allows admins to define
and manage the various access structures, specifying the required combina-
tions of entities (judges, police, bank directors) for data access.

4.2 Security Requirements

These requirements describe the overall characteristics and constraints that the
system must meet in order to be secure. In order to be able to understand
what the security requirements are, we should keep in mind the assets at stake,
detailed in Risk Analysis, and therefore need protection. Thus, our system must
provide:

1. Infrastructure Security : The system infrastructure, including hardware

such as cameras and database server, software such as the database itself,
and network components, must be secured and updated to the latest secure
version to prevent unauthorized access or disruption of service.
2. Secure Data Transmission : Surveillance data must be protected during
transmission from the cameras to the database, ensuring the confidentiality
and integrity of the data.
3. Secure Data Storage : The system should provide secure storage for the
surveillance data within the database, preventing unauthorized access or
modification.
4. Access control : Robust access control mechanisms must be implemented
to ensure that only authorized agents (judges, police, bank directors) can
access the surveillance data, as defined by the specified access structures.

5 State of the Art Jan

This chapter explores the current state of encryption techniques specifically de-
signed to secure video data during its transmission from cameras to databases,
as well as the methods used to secure this data within the database. We will
also examine robust access control systems that safeguard stored content and
the techniques employed to distribute access keys.
We begin by addressing the challenges associated with encrypting video data
during transmission. Next, we will focus on the encryption of video data within
databases and the existing access control mechanisms. Lastly, we will investigate
secret sharing techniques that enhance confidentiality and reliability in managing
sensitive information, particularly in relation to key distribution.
 Surveillance Cameras 5

5.1 Encryption of data in transit from the camera to the database

Author: Camilla Santoro

Aftab

As outlined in the project description, one of our key objectives is to safeguard

data during transmission from the camera to the database. When discussing data
protection, encryption is often the first solution that comes to mind, particularly
standard symmetric encryption algorithms like AES [10]. However, conventional
encryption techniques, which are typically optimized for text files, may not be
well-suited for video content since encrypting entire video streams introduces
significant computational overhead and can be prohibitively expensive for an IP
camera [1]. To address these challenge, W. Puech’s recent work [5], highlights
and compares various encryption techniques that can be adapted for video data,
including:

– Full encryption
– Partial encryption
– Perceptual encryption
– Crypto-compression methods

Full encryption Full encryption is the most straightforward and commonly

used method for securing video transmission. This approach, known as full sam-
ple encryption, has been standardized by MPEG under the name Common En-
cryption (CENC) for both files (ISO/IEC 23001-7 2016) and MPEG-2 video
transport streams (ISO/IEC 23001-9 2016). In full encryption, the entire com-
pressed video stream is treated as opaque data, meaning no consideration is given
to the structure or specific characteristics of the compressed content. A recent
study [1] analyzed various cryptographic algorithms, evaluating them in terms
of both security and speed. The results of this analysis, illustrated in Figure 1,
provide insights into the performance of different encryption methods.
We can observer that AES is the fastest block cipher which offers the highest
throughput for all possible key sizes while stream ciphers like ChaCha offer
significantly higher throughput due to their simplified internal structure [4].
Although full encryption is computationally demanding, it guarantees com-
plete protection of video data. In certain contexts, such as legal proceedings in
some countries, it is essential that the decrypted video maintains very high qual-
ity and that the integrity of the video is fully preserved for it to be admissible
in court [1]. For this reason, despite its complexity, full encryption can be the
most appropriate solution in cases where both security and video integrity are
paramount.
6 F. Author et al.

Fig. 1. Average Throughput of block ciphers and stream ciphers - Source:[1]

TLS Author: Entouina Stavroulla Karoulla

A widely used protocol that uses AES, and so make use of full encryption, is
TLS. Transport Layer Security (TLS) is a cryptographic protocol designed to
provide communications security over a computer network. TLS is built upon
SSL and the latest version of it is TLS 1.3 which is considered to be the most
secure. The protocol primarily aims to ensure security between client and server
communication which includes :
1. Confidentiality : Protecting the information being exchanged from unautho-
rized access.
2. Integrity : Ensuring the data transmitted has not been tampered with or
altered in transit.
3. Authenticity : Verifying the identity of the communicating parties, often
through the use of digital certificates.
TLS is consisted of two main protocols, TLS Handshake protocol and TLS
Record Protocol.
1. TLS Handshake : This part of TLS is used to negotiate the security param-
eters between a client and a server before any actual bulk data is transmitted.
Here asymmetric encryption is being used between the server and the client
in order to create a secret shared key. In a few words, after the Server has a
valid certificate issued by a Certificate Authority (CA), and a client requests
to communicate with the server with a hello message, the server responds
 Surveillance Cameras 7

Fig. 2. TLS 1.3 Handshake [8]

with his own certificate in order for the client to validate it and proceed for
a secure communication.

2. TLS Record protocol: Once the Handshake is complete, the client and
server can exchange securely data.TLS Handshake allows the client and the
server to establish cryptographic symmetric keys, called session keys which
are consisted of a set of keys for symmetric encryption and one set of sym-
metric MAC keys.uring the data transfer phase of the TLS protocol, the
client and server securely exchange information using the session keys es-
tablished during the handshake. All transmitted data is encrypted, ensuring
confidentiality so that even if intercepted, the information remains unread-
able to unauthorized parties. Additionally, each message includes a MAC
to verify its integrity, ensuring that the data has not been altered during
transmission.

Partial Encryption Author: Camilla Santoro

Partial encryption refers to securing only a portion of the bitstream (i.e., specific
bytes or bits), while leaving the rest of the data unchanged. By encrypting a lim-
ited number of bits, the complexity of cryptographic operations and the overall
computational load are significantly reduced, without fully compromising secu-
rity. One example from this algorithm family is pattern encryption, which en-
crypts specific sequences of data bytes according to a predefined pattern, leaving
other sequences unencrypted [5].

Perceptual encryption This category includes encryption methods that vi-

sually degrade video content, either entirely or in specific regions of the image.
8 F. Author et al.

Unlike standard encryption, these methods produce a protected bitstream that

can be decoded without the encryption key. For this reason, it is also referred
to as "transparent encryption" to highlight that the protected video does not
appear encrypted during transmission [1], [5]

Crypto-compression methods In this approach, both compression and en-

cryption processes are integrated into a single operational pass, leveraging cryp-
tographic mechanisms at multiple stages of the compression pipeline. These
methods inherently modify the steps of the compression process and often impact
the performance of video encoders [1], [5].

5.2 Encryption in the database and access control

Author: Eva María Benito Sanz spyros

As video content is highly critical in surveillance systems, protecting the

confidentiality, integrity, and availability of video files—the core principles
of the CIA triad—is fundamental to modern data security practices. This part
delves into encryption techniques, advanced access control models, and examines
the limitations of blockchain technology in securing video databases.

Access Control Models Access control is essential in defining who has the
authority to access or modify resources within a system, aiming to balance ease
of management, security, and flexibility. Among the various models, Attribute-
Enhanced Role-Based Access Control (AERBAC)[3] combines the role hierarchy
of Role-Based Access Control with the attribute granularity of Attribute-Based
Access Control (ABAC). This hybrid approach allows for more fine-grained and
dynamic access control policies, making it well-suited for complex systems that
require both structured roles and detailed attribute specifications.

Video Database Encryption Strategies Encryption is a critical component

in protecting sensitive video data, ensuring that even if unauthorized access
occurs, the data remains unintelligible to unauthorized parties.

Advanced Encryption Standard (AES) with Message Authentication Code (MAC)

[7]
AES is a symmetric key encryption algorithm established by the U.S. Na-
tional Institute of Standards and Technology (NIST). It has become the industry
standard for encrypting sensitive data due to its robustness and efficiency. Inte-
grating a Message Authentication Code (MAC) enhances security by ensuring
data integrity and authenticity.

– Features: AES operates on a 128-bit block size and supports key sizes of 128,
192, or 256 bits. It utilizes a substitution-permutation network structure and
 Surveillance Cameras 9

has been extensively analyzed for cryptographic strength, proving resistant

to all known attacks to date. The addition of a MAC provides a way to verify
that the data has not been altered, offering protection against tampering.
– Benefits for Video Encryption: AES with MAC is highly efficient and
can be implemented in both hardware and software, providing high through-
put with low latency—essential for handling large video files. The combined
encryption and authentication mechanisms ensure both confidentiality and
integrity of the video data.

Limitations of Blockchain for Video Encryption [2] Blockchain is a decentralized

ledger technology that employs cryptographic hashing and distributed consensus
algorithms—such as Proof of Work (PoW) or Proof of Stake (PoS)—to securely
record transactions across a peer-to-peer network. Each block contains a times-
tamp, transaction data, and a cryptographic hash of the previous block, forming
an immutable chain resistant to tampering and fraud. The decentralized nature
eliminates the need for a central authority, relying instead on network nodes to
validate and append new blocks through consensus mechanisms.
However, blockchain is not well-suited for video encryption and storage. The
technology lacks scalability for handling large files like videos because every node
must store and process all data, leading to significant redundancy and storage
inefficiency. Performance is hindered by consensus protocols that introduce la-
tency and limit transaction throughput, which is impractical for applications
requiring rapid access to large volumes of data. Additionally, the high computa-
tional and energy costs associated with maintaining and operating a blockchain
network present economic challenges, making it an inefficient solution for video
data management [11].

Combining AES with Access Control Integrating AES encryption with

advanced access control models enhances video data security by providing a
multi-layered defense mechanism.

AES with AERBAC

– Fine-Grained Control: Encrypting different video segments with separate
AES keys allows for precise control over who can access specific parts of the
content.
– Attribute-Enhanced Access: Access to decryption keys is governed by
AERBAC policies, ensuring that only users with the appropriate roles and
attributes can decrypt and view certain video content.
– Data Integrity: Incorporating a MAC ensures that any unauthorized al-
terations to the video data are detectable, maintaining the integrity of the
content.
This combined approach provides a robust and practical solution for securing
video data in databases. By leveraging the strengths of AES with MAC for
encryption and data integrity, and AERBAC for fine-grained access control, we
can achieve a secure and efficient system for managing sensitive video content.
10 F. Author et al.

Secret Sharing Author: Camilla Santoro

Secret sharing, is a technique used to distribute a secret among a group of

participants so that no single participant can access the complete secret without
cooperation. The idea was introduced independently by Adi Shamir and George
Blakley in 1979. Such schemes are ideal for storing highly sensitive and impor-
tant information. Examples include encryption keys, missile launch codes, and
numbered bank accounts. Every piece of information must be kept highly confi-
dential, as its disclosure could be catastrophic, but it is also vital that it is not
lost. Traditional encryption methods are ill-suited for simultaneously achieving
high levels of confidentiality and reliability. This is because when storing the
encryption key, one must choose between keeping a single copy of the key in one
location for maximum secrecy or keeping multiple copies of the key in different
locations for greater reliability. Increasing the reliability of the key by storing
multiple copies lowers confidentiality by creating additional attack vectors: there
are more opportunities for a copy to fall into the wrong hands. Secret-sharing
schemes address this problem and allow arbitrarily high levels of confidentiality
and reliability to be achieved.

There are two key types of secret-sharing schemes:

– Threshold Schemes: In a threshold secret sharing scheme, a secret S is divided
into n shares and distributed to n participants. Only when a predefined
number τ (where τ ≤ n), of these participants come together can the secret
be reconstructed. The scheme is denoted as (τ , n) threshold, where:
• τ is the minimum number of participants required to reconstruct the
secret.
• n is the total number of participants.
– General Access Structures: Unlike threshold secret sharing schemes, this
scheme reveals the secret only to the authorized sets of participants, not
any arbitrary set of users with cardinality more than or equal to τ .
In the "Surveillance Cameras" project, access should be provided based on
different rules and scenarios and for this reason, we decided to focus on the
threshold secret sharing scheme.

Within the threshold secret-sharing scheme (TSSS) type, the most known se-
cret sharing techniques is Shamir’s Secret Sharing Scheme, which relies on the
properties of polynomials over finite fields. As explained in the original article
published in 1979 [6], and shown in Figure 3 the scheme operates as follows:
– Secret Representation: The secret S is represented as the constant term of a
polynomial f (x) of degree t−1, where f (x) = a0 +a1 x+a2 x2 +...+at−1 xt−1 ,
and a0 = S. The coefficients a1 , a2 , ..., at−1 are randomly chosen from a finite
field.
– Share Distribution: Each participant is assigned a distinct value xi and pro-
vided with the same (xi , f (xi )). These pairs are points on the polynomial.
 Surveillance Cameras 11

– Secret Reconstruction: Given at least t points (shares), the secret can be re-
constructed by using polynomial interpolation. With fewer than t points, the
polynomial cannot be reconstructed, and hence the secret remains hidden.

Fig. 3. Shamir SSS Construction, from the book "The joy of cryptography", pg 59

6 Design aftab
This chapter presents the design of a cryptography-based solution that meets
the requirements outlined by RoboEye Inc. The solution focuses on protecting
surveillance data during transmission and storage, as well as implementing a
customizable access control mechanism that ensures only legitimate users can
access the data. Figure 4 provides an overview of the proposed design.

Fig. 4. Design of the system

6.1 Encryption from the camera to the database kazi

Author: Entouina Stavroulla Karoulla

Starting off with the data transmission from the camera to the database, we
12 F. Author et al.

will be using TLS 1.3. Firstly, obtaining a valid digital certificate from a trusted
Certificate Authority (CA) is essential. This certificate will authenticate the
server that receives the video footage, establishing trust between the camera
(client) and the database (server).
Next, the server must be properly configured to support TLS 1.3. This may
involve updating the web server or application server software to the latest ver-
sion that includes support for TLS 1.3. It is important to review and select secure
cipher suites that are compatible with TLS 1.3, as this will enhance the security
of the encrypted connections. Once the server is configured, the implementa-
tion of the TLS handshake process must be integrated into the application. This
includes programming the camera (client) to initiate the handshake by send-
ing a "Client Hello" message, which specifies the supported TLS version and
cipher suites. The server will respond with a "Server Hello" message, and the
subsequent steps of certificate exchange and key establishment must be handled
correctly to ensure a secure connection.
By focusing on these implementation steps, the secure transmission of video
footage using TLS 1.3 can be effectively achieved, ensuring that the data remains
encrypted throughout its life cycle.

6.2 Encryption in the database kazi

Author: Eva María Benito Sanz

To ensure the confidentiality and integrity of video data stored in the database,
the system employs the Advanced Encryption Standard (AES) combined with a
Message Authentication Code (MAC). AES is a symmetric-key encryption algo-
rithm widely recognized for its robustness and efficiency, as explained in Section
5.2, making it ideal for securing large volumes of data like video recordings [7].
The integration of a MAC adds an extra layer of security by ensuring that any
unauthorized alterations to the data can be detected.
When video data is transmitted from the camera to the database, it arrives
at the database server. Immediately upon arrival and before any storage occurs,
each video frame is encrypted using AES with a 256-bit key, and a MAC is
generated for each encrypted frame. This immediate encryption and authentica-
tion ensure that unencrypted data is never at rest within the system and that
any tampering can be identified, significantly reducing the risk of unauthorized
access or modification of sensitive information.
The encryption and authentication process is as follows:

1. Data Reception: Video frames are securely transmitted from the camera
to the database server over a secure communication channel, as described in
Section 5.1.
2. Encryption and MAC Generation: Upon arrival, each video frame is
encrypted using AES-256. A MAC is then generated for each encrypted
frame using a secret key and a cryptographic hash function.
 Surveillance Cameras 13

3. Key Management: The AES encryption key and the MAC key are pro-
tected using Shamir’s Secret Sharing Scheme, as detailed in Section 5.2.
4. Secure Storage: The encrypted video frames, along with their correspond-
ing MACs, are then stored in the database. Since the data is both encrypted
and authenticated, it remains secure, and any unauthorized alterations can
be detected even if the database is accessed without authorization.

By encrypting the data and generating a MAC immediately upon arrival, the
system ensures that all stored video data is both encrypted at rest and protected
against tampering. This approach eliminates any window of vulnerability where
unencrypted or unauthenticated data could potentially be accessed or altered
within the storage system, thereby enhancing the overall security and integrity
of the video data.

6.3 Access Control

Jan
Author: Camilla Santoro

Once the video frame has been confidently transmitted and stored inside the
database, access control becomes a priority to guarantee data confidentiality.
The access control technique developed for this project is based on the principle
of Shamir’s Secret Sharing Scheme, which distributes the decryption keys among
multiple authorized parties according to predefined access control policies. This
scheme ensures that only valid users can reconstruct the encryption key, hence
accessing data.
The Shamir’s Secret Sharing Scheme, as discussed in section 5.2 is used to
protect the AES encryption key, that in turn protect the video data at rest.
This cryptographic technique splits the AES key into various shares that can be
distributed among various authorized users. In performing this, the system can
ensure that multiple parties will need to collaborate in order for the data to be
decrypted; no single person will have complete access to the key.
In the proposed design, policies for access can be flexible, and customizable,
based on the sensitivity of data and the camera capturing them. In the system,
each video recording would have an associated access structure depending on
the source camera and the context of the recording. Given the location of the
camera, and so the sensitivity of the footage recorded, different individuals or
roles may possess shares of a key to AES. For example:
– Public space cameras: The video data would be less sensitive; shares of the
key could be distributed to a police officer, a city administrator, a judge and
the database administrator. In such a case at least two of these four roles
are required in order to get access to the video.
– Cameras in an investment bank: Video data can be very sensitive and hence
require a more intricate access scheme. The AES key can be shared amongst a
judge, a police officer, three bank directors, and the database administrator.
Three of six shares can be required to access the data.
14 F. Author et al.

Each camera in this system can be mapped to one access control policy cus-
tomized, which states which roles have key shares allocated to them and the
number of shares that are necessary as the threshold to reconstruct the key.
This characteristic makes the system flexible in supporting a variaty of different
access structures.
One of the challenges in access management is ensuring the system adapts
to changes in roles or the unavailability of certain users. The use of Shamir’s
Secret Sharing Scheme ensures that the system remains resilient. If a user (e.g.,
a bank director or police officer) is no longer authorized to access the data due
to role changes, retirement, or security concerns, their key share is invalidated,
and a new share is distributed among the remaining authorized parties. This
can be done without needing to re-encrypt the data. In the event that an autho-
rized user loses their key share (due to device loss or other reasons), the system
can still reconstruct the key as long as the minimum quorum of other key hold-
ers is available. In this implementation, we have distributed one extra share to
the database administrator but it is possible to tailor this solution to different
situations.

7 Evaluation and Analysis jan

Author: Zou Yong Nan Klaassen

In the evaluation and analysis the security is discussed along with weaknesses in
the system and future directions.

7.1 Security
An overview of the risks identified in the risk analysis along with the risk miti-
gations from the proposed design in table 2.

Table 2. Proposed mitigations

Asset Risks Mitigation

In transit: surveil- Information disclo- TLS
lance footage sure
In transit: surveil- Tampering TLS
lance footage
In database: surveil- Tampering MAC
lance footage
In database: surveil- Information disclo- AES,
lance footage sure Shamir’s
secret sharing

The system effectively mitigates the risk of information disclosure. AES en-
sures confidentiality by encrypting the footage in the database. Together with
 Surveillance Cameras 15

Shamir’s secrect sharing scheme it provides a robust mechanism for protect-

ing the AES encyption keys and limiting access by distributing secret shares
across multiple parties. Using MAC prevents tampering risk on the surveillance
footage at rest. TLS mitigates both the information disclosure and tampering
risks during transit from the camera to the database.

7.2 Weaknesses
The risks of spoofing, denial of service, and repudiation are not taken into con-
sideration for this project. A strategy for reducing these concerns are necessary
in the future to enhance the security of the system.

7.3 Future directions

Recommendations for mitigating the risk of spoofing, strategies are: multi-factor

authentication, digital signatures, or public key infrastructure for the surveillance
footage and the access control system. To mitigate Denial of Service, measures
such as network traffic monitoring, rate limiting, or cloud-based built in DoS
protection can help to maintain the availability during an attack.
More recommendations to enhance the overall security are to introduce reg-
ular key rotation which minimizes the chances of the keys being compromised,
and auditing to log every access attempt to the system.
16 F. Author et al.

References

[1] Sagar Dev Achar et al. “Secure Video Streaming Techniques: A Perfor-
mance Overview”. In: 2023 IEEE Guwahati Subsection Conference (GCON).
2023, pp. 01–06. doi: 10.1109/GCON58516.2023.10183567.
[2] Kyle Croman, Christian Decker, Ittay Eyal, et al. “On Scaling Decentral-
ized Blockchains”. In: International Conference on Financial Cryptography
and Data Security. Springer. 2016, pp. 106–125.
[3] D. Richard Kuhn, Edward J. Coyne, and Timothy R. Weil. “Adding At-
tributes to Role-Based Access Control”. In: Computer 43.6 (2010), pp. 79–
81.
[4] Abeer Tariq Maolood, Ekhlas Khalaf Gbashi, and Eman Shakir Mahmood.
“Novel lightweight video encryption method based on ChaCha20 stream
cipher and hybrid chaotic map”. In: International Journal of Electrical and
Computer Engineering (2022). All Open Access, Gold Open Access, Green
Open Access. doi: 10.11591/ijece.v12i5.pp4988- 5000. url: https:
//www.scopus.com/inward/record.uri?eid=2- s2.0- 85135280934&
doi = 10 . 11591 % 2fijece . v12i5 . pp4988 - 5000 & partnerID = 40 & md5 =
3b30156b2f6ceb09e09a0f7acced7222.
[5] William Puech. Multimedia security 2: Biometrics, video surveillance and
multimedia encryption. wiley, 2022.
[6] Adi Shamir. “How to share a secret”. In: Commun. ACM 22.11 (Nov.
1979), pp. 612–613. issn: 0001-0782. doi: 10.1145/359168.359176. url:
https://doi.org/10.1145/359168.359176.
[7] National Institute of Standards and Technology. “FIPS PUB 197: Ad-
vanced Encryption Standard (AES)”. In: Federal Information Processing
Standards Publication 197 (2001). Available at https://nvlpubs.nist.
gov/nistpubs/FIPS/NIST.FIPS.197.pdf, pp. 1–51.
[8] Craig Taylor. Transport Layer Security (TLS). url: https://cyberhoot.
com/cybrary/transport-layer-security-tls/s.
[9] CSF Tools. STRIDE-LM Threat Model. url: https : / / csf . tools /
reference/stride-lm/.
[10] Chung-Ping Wu and C.-C.J. Kuo. “Design of integrated multimedia com-
pression and encryption systems”. In: IEEE Transactions on Multimedia
7.5 (2005), pp. 828–839. doi: 10.1109/TMM.2005.854469.
[11] Zibin Zheng et al. “An Overview of Blockchain Technology: Architecture,
Consensus, and Future Trends”. In: 2017 IEEE International Congress on
Big Data. IEEE. 2017, pp. 557–564.