Chapter 1 — Introduction

2,556 words · source chapter1_introduction.md

CHAPTER 1: INTRODUCTION

1.1 Background

Urban parking management has become a significant component of smart-city infrastructure, driven by the measurable congestion, fuel consumption and driver time attributable to parking search — a cost Shoup [118] quantified across a series of studies in which cruising for kerb parking accounted for a substantial share of traffic in congested districts. Automated parking-occupancy monitoring has consequently attracted sustained research attention, progressing from per-space sensor installations toward camera-based systems capable of monitoring many spaces from a single vantage point [1], [2].

Camera-based approaches offer a favourable cost profile, since one sensor amortises across many bays, but impose a substantially harder perception problem involving illumination change, cast shadows, occlusion and perspective distortion [3]. Both classical image-processing methods, typified by the Canny edge detector [4], and learning-based methods evaluated on public benchmarks such as PKLot [5] and CNRPark-EXT [6] have been applied to this problem, with recent work demonstrating that convolutional inference is feasible directly on camera-class hardware [6].

In parallel, the edge computing paradigm has shifted computation from centralised servers toward the data source, motivated by response-time requirements, bandwidth cost and data privacy [33], [34]. Placing detection at the edge reduces the volume of data transmitted and limits the exposure of raw imagery. It also, however, relocates the system into a physically accessible environment. An edge node installed in a car park is not housed in a controlled data centre, and local or physical access by an adversary must be treated as a realistic assumption rather than a worst-case abstraction [35].

This relocation raises a question that the smart parking literature has largely not addressed. Extensive work measures how accurately such systems perceive occupancy [1], [2], [5], [6]; comparatively little examines whether the stored record of that perception can subsequently be trusted. Parking records are not inert. They underpin billing, enforcement, occupancy statistics used for planning, and in disputed cases may serve an evidential function. A record that can be altered after the fact without detection is of limited value in any of these roles.

The cryptographic machinery for addressing this question is long established. Haber and Stornetta [12] introduced hash-linked timestamping in 1991; Bayer et al. [13] extended it with tree structures and periodic publication to a wide witness in 1993; Schneier and Kelsey [16], [17] developed forward-secure logging for machines expected to be compromised; Crosby and Wallach [18] formalised tamper-evident logging under an untrusted logger held honest by auditors; and Certificate Transparency [21] demonstrated externally enforced append-only semantics at internet scale. What has not been established is how a minimal instance of this machinery actually behaves when deployed on constrained edge hardware and subjected to systematic adversarial evaluation — including, critically, where its guarantees cease to hold.

This thesis addresses that gap.

1.2 Problem Statement

The problem addressed by this thesis has four components.

First, current smart parking systems provide no integrity guarantees for the data they produce. Occupancy records are typically written to conventional storage with no cryptographic binding between a record and the observation that produced it. Any party with write access to that storage — including an attacker who has compromised the edge device, which the edge security literature identifies as a realistic scenario [35] — can modify, delete, inject or reorder records, and the resulting store remains internally consistent and indistinguishable from an untampered one. The attack classes involved are not hypothetical: forged video-stream injection has been demonstrated against commercial surveillance products [9], and systematic weaknesses in deployed CCTV infrastructure are well documented [8].

Second, conventional blockchain technology is unsuitable for this setting. Consensus-based distributed ledgers [25] solve the problem of agreement among mutually distrusting anonymous parties, which does not arise in a single-operator parking deployment, and do so at computational, storage and bandwidth costs repeatedly identified as prohibitive for constrained devices [29]. Permissioned systems [26] reduce but do not eliminate this overhead. Lightweight designs that replace consensus with a centrally managed hash-linked ledger [27], [28] are a better fit, but the resulting mechanism's security properties on real edge hardware remain insufficiently characterised.

Third, empirical evidence for lightweight integrity mechanisms is weak. Work applying ledger-based integrity to IoT data [30], [31], [32] typically demonstrates a proposed architecture functionally and reports overhead as an aggregate figure, without dispersion, sample size, or a statistical test against a no-mechanism baseline. Systematic evaluation against a defined attack catalogue, with replication sufficient for interval estimation, is uncommon. A practitioner selecting such a mechanism therefore has little basis on which to judge what protection it actually delivers.

Fourth, and most importantly, the conditions under which such mechanisms fail are almost never reported. Published evaluations overwhelmingly report the attacks a system detects; the attacks it does not detect, and the architectural assumptions that do not survive contact with a deployed configuration, are rarely stated. This is the more damaging omission, because a practitioner who knows a mechanism's detection rate but not its failure boundary cannot tell which threats remain unaddressed. A related gap concerns design justification: where a mechanism combines a local chain with external anchoring, the specific contribution of the chain structure — as distinct from the anchoring — is seldom isolated and measured, leaving the architecture asserted rather than demonstrated.

1.3 Research Objectives

RO1. To design and implement a multi-layer security framework for edge-based smart parking, integrating vision-based occupancy detection, edge-local processing with data minimisation on the integrity path, and a lightweight SHA-256 hash chain with cloud anchoring, deployed on constrained edge hardware.

RO2. To evaluate the integrity guarantees of the framework against a systematic catalogue of attacks derived from the video- and sensor-integrity literature, with replication sufficient to support interval estimation of detection rates.

RO3. To determine the boundaries at which those guarantees fail — identifying the attack conditions the mechanism does not detect and the architectural assumptions that do not hold as deployed — and to specify the remediation each failure requires.

RO4. To characterise the computational overhead and operational stability of the mechanism on the target device relative to a no-mechanism baseline, using appropriate hypothesis tests and confidence intervals rather than aggregate point estimates.

RO5. To determine what the chain structure contributes over independent per-record anchoring at an equal cloud-write budget, and to quantify that contribution empirically.

1.4 Research Questions

Each research question corresponds to the objective of the same number.

RQ1. What resource envelope does a multi-layer framework combining vision-based occupancy detection with a consensus-free hash chain and cloud anchoring occupy when operated continuously on constrained edge hardware, and does that envelope remain stable over sustained operation?

RQ2. To what extent does the framework detect systematic tampering with stored detection records, across the attack classes identified in the literature, and with what detection latency?

RQ3. Under what conditions do the framework's integrity guarantees fail, what are the underlying causes of those failures, and what remediation does each require?

RQ4. What computational overhead does the integrity mechanism impose on the target device relative to operation without it, and is that overhead statistically distinguishable from normal system variation?

RQ5. At an equal cloud-write budget, what tampering does the hash chain detect that independent per-record anchoring does not?

1.5 Scope and Limitations

The scope of this work is bounded as follows, and several limitations are stated here rather than deferred, because they qualify how the results of Chapter 5 should be read.

Deployment scope. The framework is implemented and evaluated on a single NVIDIA Jetson Nano monitoring a single car park with fourteen defined parking bays. Results concerning resource consumption and stability are specific to this device class. Multi-device and multi-site deployment are outside the scope of this work.

Layer 1 as carrier application. The occupancy detector is a Canny-based edge-density method with a fixed pixel threshold. It is deliberately minimal, and it is not offered as a contribution to occupancy-detection accuracy. Its role is to generate a realistic stream of detection events for the integrity layer under evaluation. As Amato et al. [6] demonstrate that convolutional inference is feasible on camera-class hardware, no claim is made that edge resource constraints compel the use of classical edge detection.

A known defect in Layer 1. Beyond being minimal, the detector as deployed is also incorrect in one respect: it applies its region-of-interest mask before running edge detection, so each region outline is itself detected as an edge and counted as scene content (§3.3.2). This is a correctness fault affecting every Layer 1 verdict reported in this thesis. It is measured and reported in Chapter 5. Layer 3 results are unaffected, because the hash chain faithfully records whatever Layer 1 reports irrespective of whether that report is correct.

Attacks were executed against synthetic chains. Experiments E1–E9 operate on baseline chains built from random bytes rather than live camera frames (§3.6.2). A SHA-256 digest of random bytes is indistinguishable from a digest of JPEG bytes for every operation the chain performs, so the integrity mechanism is measured faithfully; but no tamper-detection result in this thesis is evidence about real video content.

Power consumption was not measured. Although the platform is described in terms of power efficiency, no power measurement was conducted, and no claim about energy cost is made.

Ethical and data-protection scope. The deployment records a public car park and does not perform identification of persons or vehicles. A formal ethical review and a personal-data protection assessment were not conducted, and are identified as required work before any operational deployment beyond this study.

Threat model. The adversary is assumed capable of reading and writing the stored chain and frames, of network interception, and of camera substitution, with local or physical access to the device. The full threat model, including the assumptions that do not hold in the deployed configuration, is specified in Chapter 3.

Experimental completeness. Sixteen experiments were designed — ten tamper-detection (E1–E10), four performance benchmarks (P1–P4) and two controls (N1, N2) — of which fifteen were conducted. The exception is E10, a physical-spoofing field study, which was designed and prepared with a run-sheet but has not been executed, and no data exists for it. It is reported throughout as designed-but-not-conducted, and no result is claimed for it.

Stability measurement. The stability protocol specifies a twenty-four hour observation window. The executed run spans 23.22 hours between first and last samples, and is reported with that figure rather than as a full twenty-four hours.

Detection scope of feed substitution. The repeated-digest detection used for feed substitution identifies byte-identical repetition of frame data. A re-encoded static feed produces differing digests and is not detected by this mechanism. Results are scoped accordingly and are not presented as a general feed-substitution detection rate.

Privacy scope. The integrity path practises data minimisation: verification requires only cryptographic digests and detection metadata, and no visual content. This is a property of the integrity mechanism, not a claim about the system as a whole. In the deployed configuration, JPEG frames are additionally uploaded to a private cloud bucket as a configurable operational feature supporting dashboard, audit and labelling functions. It is therefore explicitly not claimed that raw frames never leave the device.

Terminology. The mechanism evaluated is a lightweight hash chain with cloud anchoring. It is not a blockchain: it has no consensus protocol, no distributed agreement, no peer-to-peer network and a single writer. The term "blockchain" is used only in reference to systems in the literature that genuinely employ consensus, and the qualified form "blockchain-inspired" only where that comparison is drawn explicitly.

1.6 Contributions

This thesis makes three contributions. None concerns the invention of a new cryptographic mechanism; the hash-linking and periodic-anchoring construction is prior art of 1991 [12] and 1993 [13], and this is stated explicitly rather than obscured.

Contribution 1 — An integrated, deployed framework. A three-layer framework combining vision-based occupancy detection, edge-local processing with data minimisation on the integrity path, and a lightweight hash chain with cloud anchoring, implemented on a Jetson Nano and operated continuously in a live deployment accumulating in excess of two hundred thousand chain records. Not every block corresponds to a camera frame — approximately the first three hundred were generated synthetically by an early stability pilot that ran against the production database (§5.4.2) — and the figure is reported with that qualification. The contribution is the integration and the demonstration of sustained operation on constrained hardware, not the novelty of the components.

Contribution 2 — Empirical characterisation with statistical discipline. A systematic evaluation across the attack classes identified in the literature, with 30 trials per experiment. The statistical treatment is stated precisely rather than asserted: because the outcome of a cryptographic check is deterministic, repetition quantifies timing behaviour across fixed conditions rather than sampling variability, and detection proportions carry Wilson score intervals expressing the uncertainty that remains from testing a finite number of conditions (§3.6.1). Overhead is characterised against a no-mechanism baseline using paired hypothesis tests. Two controls support the interpretation: a negative-control arm establishing the false-positive rate, and a cost-equivalent baseline isolating what the chain structure contributes over independent per-record anchoring. This addresses the evidential weakness identified in Section 1.2, where comparable work reports aggregate figures without dispersion, sample size, or any control arm.

Contribution 3 — Explicit determination of failure boundaries. The identification, measurement and honest reporting of the conditions under which the mechanism's guarantees do not hold, assessed against the criteria established by the integrity literature — forward security [16], [17], independence of the time reference [12], [23], the existence of an independent auditor [18], and externally enforced append-only semantics [21] — together with the specific remediation each failure requires. This includes attack classes the mechanism fails to detect and architectural assumptions that do not hold in the deployed configuration.

The third contribution is regarded as the most consequential. The value of an empirical study of a well-understood mechanism lies principally in establishing where it ceases to work, and those findings are presented in this thesis as primary results rather than as concessions.

1.7 Organisation of the Thesis

Chapter 2 reviews the literature: vision-based parking occupancy detection and its public benchmarks; documented attacks against video and sensor integrity; the lineage of hash chains, secure logging and trusted timestamping from which the mechanism studied here descends; lightweight and consensus-free ledgers for IoT, including the terminological position adopted; and edge computing constraints and overhead measurement methodology. It concludes with a statement of the research gap and a structured comparison against the closest related work.

Chapter 3 specifies the methodology: the system architecture and its three layers, the threat model including assumptions that do not hold as deployed, the design of the attack catalogue and the mapping of each attack class to a specific experiment, and the statistical procedures used for detection-rate and overhead analysis.

Chapter 4 describes the implementation, including hardware and software configuration, the detection pipeline, the hash chain and cloud anchoring components, and the experimental harnesses.

Chapter 5 reports results: detection rates, confidence intervals and latencies per attack class; the negative-control and cost-equivalence baselines; overhead and stability characterisation; and a discussion of the failure boundaries identified, their causes and their required remediation.

Chapter 6 concludes, revisiting each research question, restating the contributions, setting out the limitations of the work, and identifying future research directions.

References cited in this chapter follow the numbering of the consolidated thesis reference list (references_thesis.md). Verification evidence for each entry is recorded in references.md.

Chapter 2 — Literature Review

8,130 words · source chapter2_literature_review.md

CHAPTER 2: LITERATURE REVIEW

2.1 Introduction

This chapter reviews the body of work on which this thesis builds and against which its contribution must be judged. It is organised to follow the structure of the problem itself. Section 2.2 surveys vision-based smart parking systems and establishes the accuracy expectations for the occupancy-detection layer. Section 2.3 develops a taxonomy of attacks against video and sensor integrity, from which the experimental programme in Chapter 3 is derived. Section 2.4 traces the lineage of cryptographic integrity mechanisms — hash chains, secure logging and trusted timestamping — which is the core technical territory of this work. Section 2.5 examines lightweight and consensus-free distributed ledgers for the Internet of Things (IoT) and sets out the terminological position adopted throughout this thesis. Section 2.6 reviews edge computing constraints and the methodology of overhead measurement. Section 2.7 synthesises these strands into a statement of the research gap, supported by a structured comparison of the closest related work.

A note on citation practice. This chapter cites works in two distinct ways, and the distinction is stated here so that it is not mistaken for inconsistency. A comparatively small set of works is engaged individually: their trust assumptions, mechanisms or results are examined, and the argument of this thesis is positioned directly against them. These carry Sections 2.4 and 2.7, and they are the works an examiner should expect the author to defend in detail. A second, larger set is cited collectively, as instances evidencing a pattern across a field — that a research area is active, that a particular design choice recurs, or that a class of systems is consistently evaluated in a particular way. Where a group of references appears against a single proposition, the proposition is a claim about the field, and the group is the evidence for it; no individual claim is being attributed to any single member. Both uses are legitimate, and conflating them would either overstate familiarity with the second set or understate the engagement with the first.

A note on the framing of Section 2.4 is warranted at the outset. The integrity mechanism evaluated in this thesis — a hash-linked sequence of records, checkpointed periodically to an external party — is not novel in its construction. Its essential form was published in 1991 [12] and refined in 1993 [13]. This chapter states that fact directly rather than obscuring it, because the contribution claimed by this thesis is not the invention of the mechanism but the empirical characterisation of its behaviour and its failure boundaries on a constrained edge device under a realistic threat model. A literature review that concealed the age of the underlying idea would misrepresent the contribution and would not survive examination.

2.2 Smart Parking and Vision-Based Occupancy Detection

2.2.1 The smart parking problem

Urban parking search imposes measurable costs in congestion, fuel consumption and driver time, and the automation of parking-space monitoring has consequently attracted sustained research attention. Al-Turjman and Malekloo [1] survey smart parking in IoT-enabled cities, identifying the principal design axes as sensing modality, communication architecture, data interoperability and service delivery. Channamallu et al. [2] provide a more recent review, confirming that the research landscape remains dominated by questions of detection accuracy, deployment cost and user-facing service quality.

Recent work illustrates the breadth of the design space. Deployments differ in sensing modality — LoRaWAN radio propagation for space-level sensing [40], Arduino-class controllers with scheduling logic [44], and camera-based occupancy inference [37], [42] — and in architecture, from long-range wide-area network backhauls [38] to social-IoT platforms that share occupancy information between users [43]. A further strand concentrates on the user-facing service rather than the sensing layer, including deep-learning-assisted mobile applications [46], Android client design [48], and integrated management systems [39], [41]. Survey work confirms that deployment experience is now substantial [47].

Integrity is almost entirely absent from this literature. Across the surveys and the deployment studies above, systems are evaluated on how accurately they perceive occupancy and how well they serve users; the question of whether a stored occupancy record still reflects what the sensor originally reported is not posed. Detection accuracy is measured extensively; record trustworthiness is not measured at all.

The most significant exception is SAMPARK [45], which proposes secure and lightweight communication protocols for smart parking management. It is the closest prior work to this thesis within the parking domain, and the distinction between the two is precise and worth stating plainly. SAMPARK secures data in transit — authentication and confidentiality of messages exchanged between parking system entities. The present work addresses data at rest and after the fact: whether a record already written, on a device an adversary may subsequently control, can be shown to be unaltered. These are complementary rather than competing problems. A system may employ SAMPARK's protocols and still be unable to demonstrate that yesterday's stored occupancy log has not been rewritten, because transport security terminates when the message is delivered. That residual gap is the entry point for this thesis.

2.2.2 Sensor-based and vision-based approaches

Early deployments relied on per-space sensing — inductive loops, ultrasonic or magnetometer units installed at each bay. Such designs scale linearly in hardware cost and maintenance burden with the number of monitored spaces, which becomes prohibitive for large facilities [1].

Camera-based approaches amortise a single sensor across many spaces and are therefore attractive where a viewpoint covering multiple bays is available. The trade-off is a substantially harder perception problem: a fixed camera must cope with illumination change, cast shadows, inter-object occlusion, perspective distortion and weather. Huang et al. [3] address these directly, proposing a three-dimensional parking-lot model composed of planar surfaces with a plane-based classification stage, integrated through a Bayesian hierarchical framework, and demonstrate operation across both day and night conditions. Their explicit enumeration of failure modes — lighting variation, shadow, occlusion, perspective — provides the standard against which simpler detectors should be assessed.

2.2.3 Classical edge-based detection

Where computational budget is the binding constraint, classical image processing remains in use. The Canny edge detector [4] is the standard operator for this class of method. Canny derived the operator from an explicit optimisation of three criteria — good detection, good localisation, and a single response to a single edge — and the resulting pipeline of gradient computation, non-maximum suppression and hysteresis thresholding remains the reference formulation.

Occupancy detection by edge density rests on a simple premise: an empty, uniformly surfaced parking bay yields few internal edges, whereas a vehicle introduces many. Thresholding the edge-pixel count within a region of interest therefore yields a binary occupancy estimate at negligible computational cost. The method's limitations follow equally directly from its premise. It has no model of what a vehicle is, so any high-frequency content within the region — wet tarmac, painted markings, debris, shadow boundaries — contributes to the same statistic as a vehicle. A single global threshold cannot adapt to the conditions Huang et al. [3] enumerate.

The operator's structure also imposes a constraint on implementation order that is easy to violate. Because Canny operates on a gradient field computed over a neighbourhood [4], any hard boundary introduced into the image before the gradient stage is itself detected as an edge. Applying a region-of-interest mask prior to edge detection therefore injects a synthetic contour at the mask perimeter, which is subsequently counted as image content. The correct order is to detect edges over the unmasked image and mask the resulting edge map. This distinction is not a matter of optimisation but of correctness, and Chapter 3 documents its treatment in the present implementation.

2.2.4 Learning-based detection and public benchmarks

The introduction of public benchmarks transformed evaluation in this field. PKLot [5] provides 695,899 segmented parking-space images extracted from 12,417 full camera frames captured across multiple sites, each space manually labelled as vacant or occupied and additionally annotated with the prevailing weather condition (sunny, overcast or rainy), permitting evaluation stratified by condition rather than in aggregate alone. The distinction between frames and segmented spaces matters for the comparison drawn below.

Amato et al. [6] extend this work in two respects directly relevant to the present thesis. First, they introduce CNRPark-EXT, a dataset of approximately 150,000 labelled patches drawn from a 164-space car park. Second, and more significantly, they propose a convolutional neural network designed specifically for execution on smart cameras, arguing for decentralised occupancy detection in which inference occurs at the camera rather than at a central server. Acharya et al. [7] pursue a related approach, combining a pre-trained CNN with a binary support vector machine classifier and evaluating on PKLot.

The implication for the present work must be stated plainly. Amato et al. [6] demonstrate that CNN-based occupancy detection is feasible on camera-class hardware. Consequently, a claim that edge resource constraints compel the use of classical edge detection is not defensible in the current literature. The use of a Canny-based detector in this thesis is properly justified on different grounds — as a deliberately minimal, computationally negligible carrier application whose purpose is to generate a realistic stream of detection events for the integrity layer under evaluation — and not as a state-of-the-art perception contribution. This distinction is maintained throughout the thesis.

A second implication concerns evaluation scale. Against benchmarks of 695,899 [5] and approximately 150,000 [6] labelled space instances, the evaluation conducted here — one hundred frames yielding 1,400 labelled slot readings — is smaller by more than two orders of magnitude, and conclusions drawn from it must be correspondingly qualified.

2.3 Attacks on Video and Sensor Data Integrity

The experimental programme of this thesis evaluates a defined set of attacks. This section establishes that those attacks are drawn from documented threat classes rather than constructed for convenience.

2.3.1 Threats to deployed surveillance infrastructure

Costin [8] presents a systematic review of threats, vulnerabilities and attacks against CCTV and IP-camera systems, drawing on publicly documented weaknesses across firmware, network communication and operational practice. The review establishes that surveillance infrastructure is routinely deployed with weak or default credentials, unauthenticated streaming interfaces and unpatched firmware, and that these are observed conditions in fielded systems rather than theoretical concerns.

Obermaier and Hutle [9] provide the sharpest empirical result for present purposes. Examining commercially available cloud-connected surveillance products under two attacker models, and reverse-engineering their security implementations, they report vulnerabilities in every system tested. Critically, they demonstrate injection of forged video streams, alongside denial-of-service and eavesdropping on private video data. Feed substitution is therefore a demonstrated attack against real products, not a hypothesis, and its inclusion in the experimental programme of this thesis requires no further justification.

2.3.2 Video forensics and the active–passive distinction

The video forensics literature divides broadly into passive and active techniques. Sitara and Mehtre [10] survey passive methods, which infer tampering from statistical or physical inconsistencies in the content itself without requiring any information recorded at capture time. Wang and Farid [11] give an influential example, detecting frame duplication through correlation between candidate frame sequences.

This division locates the present thesis precisely. Passive forensics answers the question "does this video bear traces of manipulation?" after the fact and without prior preparation. The approach taken here is active: a cryptographic commitment is computed at the moment of capture and retained, so that subsequent verification is a comparison against a prior commitment rather than an inference from content statistics. Active methods require foresight and infrastructure that passive methods do not; in exchange they yield a decisive rather than probabilistic answer within their scope.

The contrast with Wang and Farid [11] is instructive for scoping. Their method detects duplication through content correlation and therefore remains effective when duplicated frames are re-encoded, since correlation survives moderate recompression. A detector operating instead on cryptographic digests of frame bytes will identify byte-identical repetition exactly, but any re-encoding alters the digest and defeats it. Digest-based repetition detection and correlation-based duplication detection therefore have materially different scopes, and results obtained by the former must not be presented as though they had the generality of the latter. Chapter 3 bounds the relevant experiment accordingly.

2.3.3 Ledger-based approaches to video integrity

A small body of work applies distributed-ledger techniques directly to video data, and it is the most immediate precedent for the architecture evaluated here. Jeong et al. [68] apply blockchain to the management of video surveillance systems: video metadata is recorded on a distributed ledger maintained by trusted internal managers so that forgery of that data is prevented, while the video itself is encrypted and stored separately and released under a licence issued within the ledger. The separation of a compact ledger-committed record from bulk storage of the media is the same division adopted in this thesis. Dhiran et al. [67] address video fraud detection using blockchain, presented as a comparative study with a prototype examining the practicability of the approach.

A related strand addresses video delivery rather than integrity, using ledgers to coordinate resource allocation for transcoding and streaming at the network edge [69], [70]. These are included here to delimit the boundary: they employ similar infrastructure for an unrelated purpose, and are not integrity mechanisms.

The pattern established by [68] — commit a compact record to a tamper-evident store, retain the media separately, verify later — is the pattern this thesis implements. The distinction claimed here is not architectural novelty but evaluation: these works demonstrate their systems functionally, whereas the present study measures detection rates per attack class with replication, and reports the conditions under which the mechanism fails. Both also retain a consensus-based ledger, whereas the present work removes consensus entirely (§2.5).

2.3.4 Attack classes addressed

Synthesising the above, the threat classes relevant to a stored sequence of detection records are: modification of recorded content; deletion of records; injection of fabricated records; alteration of record metadata; alteration of stored cryptographic digests; replay of previously valid records; wholesale rewriting of the stored sequence; substitution of the input feed [9]; manipulation of recorded time; and physical manipulation of the scene so that a correctly functioning detector reports a false state. Chapter 3 maps each of these to a specific experiment.

2.4 Integrity Mechanisms: Hash Chains, Secure Logging and Trusted Timestamping

This section reviews the lineage from which the mechanism evaluated in this thesis descends. It is the most important section of this chapter, because the central question an examiner will and should put to this work — what does this add to results published in 1991? — is answered here.

2.4.1 Cryptographic hash functions

The mechanisms below rest on a cryptographic hash function providing preimage and collision resistance. This thesis uses SHA-256, specified in NIST FIPS PUB 180-4 [24]. Standardisation matters here for two reasons: the security properties relied upon are those asserted by the standard, and the performance figures reported in Chapter 5 measure a standardised primitive whose implementation characteristics are comparable across platforms.

2.4.2 Digital timestamping: Haber and Stornetta

The foundational result is due to Haber and Stornetta [12]. Addressing the problem of certifying when a digital document was created or last modified, they set an objective that remains the reference standard: that it be infeasible for a user to back-date or forward-date a document even with the collusion of a time-stamping service, while preserving the privacy of document content and requiring no record-keeping by the service.

Two aspects of this formulation are decisive for the present thesis.

First, the mechanism. Haber and Stornetta's linking scheme binds each timestamp request to its predecessors by including the previous request's hash in the current record, producing a sequence in which any retrospective alteration invalidates all subsequent links. This is the construction that the present work implements. It is therefore incumbent on this thesis to state that hash-linking records into a tamper-evident sequence is prior art of 1991, not a contribution of this work.

Second, and more importantly, the trust model. It is a common misreading to suppose that their scheme depends on a trusted timestamping service. The opposite is the case: eliminating that trust is precisely their contribution. Only the naive construction requires a trusted service; the linking scheme and the distributed-random-witness scheme exist specifically to remove it, so that the timestamp remains sound even if the service colludes with the client [12].

This sets a demanding standard, and it is the standard against which the cloud anchoring mechanism of this thesis must be assessed. Where the time associated with a record is generated by the same party whose records are being audited, there is no second party to the timestamp at all — a position weaker than even the naive 1991 construction, which at least separated the issuing service from the client. Chapter 3 documents the implementation's actual behaviour in this respect, and Chapter 5 evaluates the consequences. Stating the standard here, in the literature review, is deliberate: the limitation is a known and characterised property of the system, not an oversight discovered by the reader.

2.4.3 Efficiency and wide witness: Bayer, Haber and Stornetta

Bayer, Haber and Stornetta [13] extend the 1991 work in a direction equally relevant here. They reformulate timestamping over tree structures and demonstrate an exponential increase in the "publicity" obtained per timestamping event, while simultaneously reducing the storage and computation required to validate an individual certificate.

The significance is that periodic publication of a compact digest to a wide audience, so that no single service need be trusted, is a published technique of 1993. Cloud anchoring — periodically writing a checkpoint digest to an external, independently held store — is an instance of this idea. The design freedom that remains is not whether to anchor but how often, and with what consequences for the window during which undetected tampering is possible, for bandwidth, and for cost. That parameter space, rather than the anchoring concept, is where a contemporary contribution can legitimately be located.

2.4.4 Hash trees

The tree structures employed by Bayer et al. [13] originate with Merkle [14], who introduced the hash tree in the course of comparing protocols for public-key distribution and digital signatures, and developed it further into a signature scheme built solely from a conventional encryption function, with signature size growing only logarithmically in the number of messages signed [15].

The relevance is a design decision that must be justified rather than assumed. A linear hash chain and a Merkle tree offer different verification complexities: a chain requires traversal proportional to its length to verify fully, whereas a tree supports membership proofs logarithmic in the number of leaves. A system that adopts a chain and later finds full verification expensive at scale has encountered a consequence of a known trade-off, not an unforeseen defect. This thesis adopts a chain for implementation simplicity on constrained hardware and measures the resulting verification cost empirically in Chapter 5, presenting it as a characterised trade-off against the tree alternative.

2.4.5 Secure logging on untrusted machines

A parallel line of work addresses a threat model closer still to that of this thesis. Schneier and Kelsey [16], [17] consider log files held on a machine that will eventually be compromised, and construct a scheme in which entries written before compromise remain impossible for the attacker to read and impossible to modify or destroy undetectably, achieved by evolving the authentication key forward and irreversibly destroying its predecessor.

The property is forward security, and it is the correct lens for evaluating any edge-deployed integrity mechanism. The threat is not an abstract adversary but the concrete situation in which the recording device itself falls under an attacker's control. Schneier and Kelsey's premise is that this will happen; their design ensures the historical record survives it.

An architecture in which the recording device retains, at the moment of compromise, all credentials necessary to rewrite both its local records and their external checkpoints does not possess forward security in this sense. Chapter 3 specifies the credentials held by the device in the deployed configuration, and Chapter 5 evaluates the consequences against this criterion.

Holt [20] extends the approach by adding public verification, allowing log verification to be performed by parties other than the holder of a private verifier key, thereby separating log creation from log verification. Ma and Tsudik [19] take a different route, applying forward-secure sequential aggregate authentication to obtain compact, provably secure tamper evidence without reliance on an online trusted third party or secure hardware. Their result frames an important question for any design that introduces an external dependency: what does the external party provide that a purely local forward-secure construction does not? A satisfactory answer must identify a property genuinely unobtainable locally — such as evidence surviving destruction of the device — rather than merely asserting that external storage is more trustworthy.

2.4.6 Tamper-evident logging with untrusted loggers

Crosby and Wallach [18] address a configuration in which the logger itself is untrusted while serving multiple clients, and is held honest by auditors who periodically issue challenges requiring the logger to prove its correct behaviour. Their tree-based construction generates tamper-evidence proofs logarithmic in both size and computation, improving on earlier linear constructions, and additionally supports controlled deletion of old events.

The structural lesson is the auditor. Tamper evidence is only realised when some party actually performs verification, and that party must be distinct from the party capable of tampering. A design in which the device that writes the log is also the sole party that verifies it provides tamper evidence in the cryptographic sense while providing no tamper detection in operational terms, because the only verifier is precisely the entity the mechanism must be robust against. Chapter 3 addresses the verification arrangement adopted here in the light of this requirement.

2.4.7 Certificate Transparency: append-only enforced externally

Certificate Transparency (CT), specified in RFC 6962 [21] and described for a general audience by Laurie [22], is the most instructive contemporary system for this thesis, because it addresses exactly the failure mode identified above.

CT publicly logs TLS certificates in append-only logs built on Merkle trees. Its essential design decision is that it does not ask the log operator to behave correctly. Append-only behaviour is made externally checkable: logs publish signed tree heads, issue signed certificate timestamps as promises of inclusion, and are policed by independent monitors and auditors who verify consistency between published states over time. Misbehaviour by the log operator is detectable by parties other than the operator. The system's trust assumption is that the log operator is untrusted.

Two conclusions follow for the present work. First, CT provides the design pattern for making an anchoring mechanism robust: append-only semantics must be enforced and verified by a party other than the writer, with commitments pinned to specific verifiable states. Second, and following directly, a control that the writing party can simply choose not to apply is not an enforcement mechanism. A conditional-write guard applied by the client is discretionary for any holder of the write credential; enforcement must be a property of the storage service itself. Chapter 3 specifies the requirements this imposes, and Chapter 5 evaluates the deployed configuration against them.

2.4.8 Standardised timestamping

For completeness, the standardised realisation of third-party timestamping is the Time-Stamp Protocol of RFC 3161 [23], defining the request and response formats for a Time Stamping Authority (TSA) and the security requirements governing its operation. RFC 3161 represents the institutional form of the requirement identified by Haber and Stornetta: a time reference issued and attested by a party distinct from the entity whose data is being timestamped. It is the appropriate reference point for what a system claiming an independent time reference must actually provide.

2.5 Lightweight and Consensus-Free Ledgers for IoT

2.5.1 Consensus-based blockchains and their cost

Nakamoto [25] combined hash-linked blocks with proof-of-work and a peer-to-peer network to achieve distributed agreement among mutually untrusting parties without a central authority. The construction solves a problem — decentralised consensus among anonymous participants with economic incentives — that does not arise in a single-operator parking deployment, and it does so at a computational and bandwidth cost that is well documented as unsuitable for constrained devices [29]. The energy cost of proof-of-work in particular has drawn sustained criticism on sustainability grounds [57], a further reason to avoid it where the problem it solves is absent.

Permissioned systems relax these assumptions. Hyperledger Fabric [26] supports modular consensus, executes applications written in general-purpose languages, and requires no native cryptocurrency, employing an execute-order-validate architecture in place of the conventional order-execute model. Fabric occupies an intermediate position: participants are known and authenticated, but multiple mutually distrusting organisations remain, and consensus machinery is still required.

2.5.2 Lightweight blockchain designs for IoT

Blockchain-based IoT security has become a substantial literature in its own right, with multiple surveys mapping the field [56], [62], [63], [65] and numerous proposed architectures addressing access control, key management and data protection [53], [54], [55], [58], [59], [60]. Reyna et al. [29] survey blockchain–IoT integration and document the recurring obstacles: computational cost, storage growth, latency and bandwidth, all acute on constrained hardware.

Architectural responses vary widely. Some couple the ledger with software-defined networking to manage resources [61], others propose multi-dimensional or hierarchical ledger structures for scalability [66], and others again combine ledgers with machine learning for threat detection [64], [83]. Application-domain studies extend the pattern to healthcare records [52], supply-chain finance [51], and transportation [50], while broader reviews position ledgers alongside edge computing and artificial intelligence as converging infrastructure [49].

These works are cited collectively, and the aggregate is what carries the argument. Two observations follow, neither of which could be supported by a smaller sample. First, the sheer volume confirms that ledger-backed integrity for IoT data is an established rather than speculative approach — this thesis is not proposing something the field has ignored, and cannot claim novelty on those grounds. Second, and more consequentially, across this body of work two properties hold almost without exception: the proposals retain consensus machinery, and they are validated by demonstrating that the proposed architecture functions rather than by measuring what an adversary can and cannot do against it. The consistency of those two patterns across more than twenty independent proposals is the empirical basis for the research gap stated in Section 2.7, and it is why that gap is characterised as evidential rather than mechanical.

Dorri et al. [27] respond with an architecture that is the most direct precedent for the position taken in this thesis. For resource-constrained devices they replace distributed consensus with a centrally managed immutable ledger, retaining hash-linked tamper evidence while eliminating the consensus overhead, and delegate public distributed-ledger participation to higher-resource overlay nodes. Their extended design, LSB [28], adds distributed throughput management and a time-based consensus algorithm intended to be low-cost for constrained participants.

The significance for this thesis is that removing consensus from a hash-linked ledger for constrained devices is an established and peer-reviewed design position [27], [28], not an incomplete implementation of a blockchain.

2.5.3 Ledger-based data integrity and provenance

ProvChain [30] is the closest neighbour to the present work in purpose. It records data-provenance events by embedding provenance records into ledger transactions, operating in three phases — collection, storage and validation — and reports low overhead for cloud storage applications. The architectural pattern is the same as that adopted here: hash the event, commit the digest to an external tamper-evident store, verify later against that commitment.

Related work applies comparable patterns at larger scale. Medhane et al. [31] present a blockchain-enabled distributed security framework for next-generation IoT combining edge-cloud resources with software-defined networking, and Rahman et al. [32] propose a hierarchical, interoperable blockchain platform for ensuring IoT data integrity in smart-city deployments. Both establish that ledger-backed integrity for IoT data is an active research area; both employ machinery substantially heavier than a single-writer hash chain.

2.5.4 Terminological position adopted in this thesis

Given the above, the terminology used throughout this thesis is stated explicitly.

The mechanism evaluated here is a lightweight hash chain with cloud anchoring. It is not a blockchain. It has no consensus protocol, no distributed agreement, no peer-to-peer network, no mining or validator set, no incentive layer and no multi-writer conflict resolution. It has a single writer. Applying the term "blockchain" to it would overstate its properties and invite objections it cannot answer.

The term "blockchain" is therefore used in this thesis only when referring to systems in the literature that genuinely employ consensus [25], [26], [27], [28], and the qualified form "blockchain-inspired" only where the comparison to that literature is being drawn explicitly. This is a deliberate constraint on claims, adopted so that what is claimed corresponds exactly to what was built and measured.

2.6 Edge Computing Constraints and Overhead Measurement

2.6.1 The edge computing paradigm

Shi et al. [33] define edge computing as the placement of computation and storage near the data source, motivated by response-time requirements, bandwidth cost, and data privacy. Satyanarayanan [34] develops the same argument, emphasising responsiveness, scalability for IoT, privacy-policy enforcement, and resilience to transient cloud outages.

The paradigm has since developed considerable depth. Much of the work concerns resource management — task offloading between device and edge [96], service caching [91], deadline-constrained job dispatch [98], collaborative computing across devices [94], and dynamic access management [104] — with recent surveys extending these questions to federated learning [97] and to next-generation wireless networks [77], [93]. A second strand addresses the execution substrate itself, including lightweight virtualisation for deeply embedded systems [101], FPGA-based acceleration [100], embedded microcontroller platforms [105], and hardware-agnostic programming models [103]. Application studies range from ridesharing monitoring [95] to sustainable manufacturing [80].

Two of these bear directly on the present design. Sánchez et al. [99] map edge computing for cyber-physical systems with explicit emphasis on trustworthiness, and Kenioua et al. [92] examine authentication for edge architectures — both addressing, from different directions, the question of what may be believed about an edge node and its output.

These motivations bear directly on the architecture evaluated here. Where integrity verification depends only on cryptographic digests and detection metadata, the data required for verification is small and contains no visual content — so the integrity path can operate on minimal data regardless of how the application handles imagery. This property, and its precise boundaries in the deployed system, are specified in Chapter 3.

2.6.2 Security in edge deployments

Roman et al. [35] survey security threats across edge paradigms including mobile edge computing, fog computing and mobile cloud computing, and identify concerns common to all: the physical accessibility of edge nodes, their frequently limited capacity for protective measures, and the difficulty of establishing trust in distributed deployments.

Physical accessibility is the pertinent point. An edge node placed in a car park is not in a controlled data centre; local or physical access by an adversary is a realistic assumption rather than a worst-case abstraction. This directly supports the threat model adopted in Chapter 3 and is the reason device-level compromise is treated as in scope rather than excluded.

2.6.3 Computer vision at the edge

Vision workloads are among the most common drivers of edge deployment, since video is expensive to transmit and often privacy-sensitive, making local inference attractive. The application literature is broad: automated fire detection and alarm [73], wildfire behaviour segmentation from aerial imagery [84], structural health monitoring [82], industrial safety systems [81], analogue gauge digitisation [78], agricultural and precision-farming systems [75], construction progress monitoring [76], [72], robotised assembly [71], and quantitative measurement in laboratory settings [79]. General treatments of image and video analysis [86], [87] and systematic reviews of deep-learning video processing [89] map the underlying techniques, while dedicated studies address video processing architectures at the fog and edge layers [85], [90].

This group is cited collectively, in the sense set out in Section 2.1. The breadth is the point: across sixteen studies spanning agriculture, construction, manufacturing, emergency response and laboratory measurement — domains with no common methodology and no shared authorship — edge vision systems are evaluated on detection performance and resource cost, and in none of them is the integrity of the recorded output treated as a property requiring evaluation. A narrower selection could not support that claim, because the claim is precisely that the omission is uniform rather than incidental. The gap identified in Section 2.2 for parking specifically therefore generalises to edge vision applications at large.

One entry is engaged individually. Gebrye et al. [74] apply computer vision to denial-of-service detection on resource-limited devices — an inversion of the usual relationship, in which vision becomes the security mechanism rather than the workload being secured. It is the exception that locates the boundary of the pattern above.

2.6.4 Communication substrates and the boundary of this work

Edge and IoT deployments require a communication substrate, and a substantial literature addresses this layer — particularly 6LoWPAN, which adapts IPv6 to low-power wireless networks. Work here covers authentication and key agreement [106], [107], [110], neighbour-discovery security [112], intrusion detection [88], [108], data security assessments [116], network lifetime and quality-of-service optimisation [117], [115], simulation and performance analysis [111], [114], software-defined networking integration [102], and application architectures for home automation [113] and environmental monitoring [109].

This layer is deliberately outside the scope of the present work, and the boundary is stated here rather than left implicit. The body of work above is cited collectively, in the sense set out in Section 2.1, to establish a single proposition: that when this literature addresses security for constrained IoT deployments, it addresses it almost exclusively as a transport problem — authentication, key agreement, neighbour discovery, intrusion detection at the network layer. That consistency across fourteen independent studies is itself the evidence, and it matters because it shows the gap this thesis addresses is not peculiar to parking: securing the channel is treated as the security question, and the integrity of what was written at the end of the channel is not asked. The system evaluated in this thesis communicates over conventional IP networking — RTSP from the camera and HTTPS to cloud services — and does not employ a low-power wireless substrate. The threat model of Section 2.3 concerns the integrity of records after capture, which is orthogonal to the transport used to move them. This literature is surveyed here because it defines the adjacent problem space, and because securing the transport does not address the question this thesis asks: whether a record already written can later be shown to be unaltered. That distinction is the same one drawn against SAMPARK [45] in Section 2.2.1.

2.6.5 Measuring overhead on embedded platforms

Claims that a security mechanism is "lightweight" require measurement against a defined baseline on the target hardware. Süzen et al. [36] provide a comparative benchmark of the NVIDIA Jetson Nano, Jetson TX2 and Raspberry Pi under CNN workloads, reporting GPU, CPU, memory and power consumption alongside accuracy and cost, and thereby establish external reference points for the resource envelope of Jetson-class devices.

Two methodological observations follow. First, published embedded benchmarks concentrate on inference workloads; comparable published figures for cryptographic hashing throughput on these platforms are scarce, which limits external comparison for that specific measurement. Second, and more importantly, overhead claims in the lightweight-ledger literature are frequently reported as single aggregate figures without dispersion, sample size, or a statistical test against a no-mechanism baseline. Where a mechanism's overhead is small relative to normal system variance, a single measurement cannot distinguish a real effect from noise. This observation motivates the measurement design adopted in Chapter 3.

2.7 Research Gap

2.7.1 Synthesis

Four findings emerge from the foregoing review.

First, the smart parking literature measures detection accuracy but does not address the integrity of stored detection records [1], [2]. The question of whether a parking record still reflects what was originally observed is not posed.

Second, the cryptographic machinery required to address that question has been available for three decades. Hash-linking is due to Haber and Stornetta [12]; periodic publication to a wide witness to Bayer et al. [13]; forward-secure logging on untrusted machines to Schneier and Kelsey [16], [17]; auditor-enforced tamper-evident logging to Crosby and Wallach [18]; and externally enforced append-only semantics to Certificate Transparency [21]. No part of the underlying mechanism is novel, and this thesis does not claim otherwise.

Third, work applying ledger-based integrity to IoT data [27], [28], [30], [31], [32] establishes both the applicability of the approach and a consistent pattern in how it is evaluated: proposed architectures are demonstrated functionally, with overhead reported in aggregate. Systematic evaluation against a defined catalogue of attacks, with sufficient repetition to support interval estimates, and with explicit reporting of the conditions under which the mechanism fails, is not the norm.

Fourth, the threat model most relevant to an edge deployment — compromise of the recording device itself [35] — is precisely the model under which the classical secure-logging literature [16], [17] defines its central property, forward security. Contemporary lightweight-ledger designs for IoT are seldom evaluated against it.

2.7.2 The gap addressed by this thesis

The gap is therefore not mechanical but evidential. What is absent from the literature is not another integrity architecture, but a rigorous empirical characterisation of how a minimal hash-chain-plus-anchoring mechanism actually behaves on real constrained hardware when subjected to a systematic catalogue of attacks — including, and especially, an honest account of the attacks it does not detect and the boundaries at which its guarantees fail.

Accordingly this thesis contributes:

1. A systematic attack evaluation across the threat classes identified in Section 2.3, with repetition sufficient for interval estimation, reporting detection rates and latencies per attack class — including classes where detection fails.
2. A statistically disciplined overhead characterisation on a Jetson-class device, comparing against a no-mechanism baseline with appropriate hypothesis tests and confidence intervals rather than aggregate point estimates.
3. An explicit account of the mechanism's failure boundaries, evaluated against the criteria established by the literature reviewed above — forward security [16], [17], the independence of the time reference [12], [23], the existence of an independent auditor [18], and externally enforced append-only semantics [21] — together with the specific remediation each requires.

The third contribution is the one this thesis regards as most consequential. The value of an empirical study of a well-understood mechanism lies principally in establishing where it stops working, and that is reported here as a primary result rather than as a concession.

2.7.3 Comparison with related work

Table 2.1 positions this thesis against the most closely related work along the dimensions identified above.

Table 2.1: Comparison of related integrity work

Two qualifications apply to Table 2.1. First, "not reported" indicates that the dimension was not stated in the cited work; it is not a claim that the work is deficient, since these dimensions were not among its stated objectives. Second, the final row describes the evaluation design of this thesis as specified in Chapter 3; the results themselves, including those experiments whose targets were not met, are reported in Chapter 5.

2.8 Summary

This chapter has established the position of the present work. Vision-based smart parking is a mature field in which detection accuracy is measured thoroughly and data integrity is not considered [1], [2], [6]. Attacks against video and sensor integrity are documented empirically against fielded systems, including forged-stream injection [8], [9]. The cryptographic mechanisms for addressing such attacks were established between 1980 and 2013 [12]–[24], and this thesis makes no claim of novelty in that machinery. Contemporary work applies these mechanisms to IoT data but evaluates them functionally rather than adversarially and statistically [27]–[32].

The contribution claimed is therefore evidential rather than mechanical: a systematic, statistically disciplined characterisation of a minimal integrity mechanism on real constrained hardware, including explicit determination of the conditions under which its guarantees fail, assessed against the criteria the literature reviewed here has established. Chapter 3 specifies the methodology by which that characterisation is obtained.

Core reference set

This chapter cites entries [1]–[117]. Reproduced below are the core entries [1]–[36], which carry the argument of Sections 2.4 and 2.7; the remaining entries [37]–[117] appear in the consolidated list. The complete reference list for the thesis is references_thesis.md.**

Numbering is provisional and will be unified across the full thesis at final assembly. Verification records — DOIs and the evidence by which each entry was confirmed — are maintained in references.md.

[1] F. Al-Turjman and A. Malekloo, "Smart parking in IoT-enabled cities: A survey," Sustainable Cities and Society, vol. 49, art. 101608, 2019. doi: 10.1016/j.scs.2019.101608

[2] S. S. Channamallu, S. Kermanshachi, J. M. Rosenberger, and A. Pamidimukkala, "A review of smart parking systems," Transportation Research Procedia, vol. 73, pp. 289–296, 2023. doi: 10.1016/j.trpro.2023.11.920

[3] C.-C. Huang, Y.-S. Tai, and S.-J. Wang, "Vacant parking space detection based on plane-based Bayesian hierarchical framework," IEEE Transactions on Circuits and Systems for Video Technology, vol. 23, no. 9, pp. 1598–1610, 2013. doi: 10.1109/TCSVT.2013.2254961

[4] J. Canny, "A computational approach to edge detection," IEEE Transactions on Pattern Analysis and Machine Intelligence, vol. PAMI-8, no. 6, pp. 679–698, 1986. doi: 10.1109/TPAMI.1986.4767851

[5] P. R. L. de Almeida, L. S. Oliveira, A. S. Britto Jr., E. J. Silva Jr., and A. L. Koerich, "PKLot – A robust dataset for parking lot classification," Expert Systems with Applications, vol. 42, no. 11, pp. 4937–4949, 2015. doi: 10.1016/j.eswa.2015.02.009

[6] G. Amato, F. Carrara, F. Falchi, C. Gennaro, C. Meghini, and C. Vairo, "Deep learning for decentralized parking lot occupancy detection," Expert Systems with Applications, vol. 72, pp. 327–334, 2017. doi: 10.1016/j.eswa.2016.10.055

[7] D. Acharya, W. Yan, and K. Khoshelham, "Real-time image-based parking occupancy detection using deep learning," in Proc. 5th Annu. Conf. Research@Locate, Adelaide, Australia, CEUR Workshop Proceedings, vol. 2087, pp. 33–40, 2018.

[8] A. Costin, "Security of CCTV and video surveillance systems: Threats, vulnerabilities, attacks, and mitigations," in Proc. 6th Int. Workshop on Trustworthy Embedded Devices (TrustED '16), Vienna, Austria, pp. 45–54, 2016. doi: 10.1145/2995289.2995290

[9] J. Obermaier and M. Hutle, "Analyzing the security and privacy of cloud-based video surveillance systems," in Proc. 2nd ACM Int. Workshop on IoT Privacy, Trust, and Security (IoTPTS '16), Xi'an, China, 2016. doi: 10.1145/2899007.2899008

[10] K. Sitara and B. M. Mehtre, "Digital video tampering detection: An overview of passive techniques," Digital Investigation, vol. 18, pp. 8–22, 2016. doi: 10.1016/j.diin.2016.06.003

[11] W. Wang and H. Farid, "Exposing digital forgeries in video by detecting duplication," in Proc. 9th Workshop on Multimedia & Security (MM&Sec '07), pp. 35–42, 2007. doi: 10.1145/1288869.1288876

[12] S. Haber and W. S. Stornetta, "How to time-stamp a digital document," Journal of Cryptology, vol. 3, no. 2, pp. 99–111, 1991. doi: 10.1007/BF00196791

[13] D. Bayer, S. Haber, and W. S. Stornetta, "Improving the efficiency and reliability of digital time-stamping," in Sequences II, R. Capocelli, A. De Santis, and U. Vaccaro, Eds. New York, NY: Springer, 1993, pp. 329–334. doi: 10.1007/978-1-4613-9323-8_24

[14] R. C. Merkle, "Protocols for public key cryptosystems," in Proc. 1980 IEEE Symp. on Security and Privacy, Oakland, CA, USA, pp. 122–134, 1980.

[15] R. C. Merkle, "A digital signature based on a conventional encryption function," in Advances in Cryptology — CRYPTO '87, Lecture Notes in Computer Science, vol. 293. Berlin, Heidelberg: Springer, 1987, pp. 369–378. doi: 10.1007/3-540-48184-2_32

[16] B. Schneier and J. Kelsey, "Cryptographic support for secure logs on untrusted machines," in Proc. 7th USENIX Security Symp., San Antonio, TX, USA, pp. 53–62, 1998.

[17] B. Schneier and J. Kelsey, "Secure audit logs to support computer forensics," ACM Transactions on Information and System Security, vol. 2, no. 2, pp. 159–176, May 1999. doi: 10.1145/317087.317089

[18] S. A. Crosby and D. S. Wallach, "Efficient data structures for tamper-evident logging," in Proc. 18th USENIX Security Symp., Montreal, QC, Canada, pp. 317–334, 2009.

[19] D. Ma and G. Tsudik, "A new approach to secure logging," ACM Transactions on Storage, vol. 5, no. 1, art. 2, pp. 1–21, 2009. doi: 10.1145/1502777.1502779

[20] J. E. Holt, "Logcrypt: Forward security and public verification for secure audit logs," in Proc. 2006 Australasian Workshops on Grid Computing and e-Research (ACSW Frontiers '06), pp. 203–211, 2006.

[118] D. C. Shoup, "Cruising for parking," Transport Policy, vol. 13, no. 6, pp. 479–486, 2006. doi: 10.1016/j.tranpol.2006.05.005

[21] B. Laurie, A. Langley, and E. Kasper, "Certificate Transparency," RFC 6962, Internet Engineering Task Force, June 2013. doi: 10.17487/RFC6962

[22] B. Laurie, "Certificate transparency," Communications of the ACM, vol. 57, no. 10, pp. 40–46, 2014. doi: 10.1145/2659897

[23] C. Adams, P. Cain, D. Pinkas, and R. Zuccherato, "Internet X.509 public key infrastructure time-stamp protocol (TSP)," RFC 3161, Internet Engineering Task Force, Aug. 2001. doi: 10.17487/RFC3161

[24] National Institute of Standards and Technology, Secure Hash Standard (SHS), FIPS PUB 180-4, Aug. 2015. doi: 10.6028/NIST.FIPS.180-4

[25] S. Nakamoto, "Bitcoin: A peer-to-peer electronic cash system," self-published white paper, Oct. 2008. [Online]. Available: https://bitcoin.org/bitcoin.pdf

[26] E. Androulaki et al., "Hyperledger Fabric: A distributed operating system for permissioned blockchains," in Proc. 13th EuroSys Conf. (EuroSys '18), Porto, Portugal, pp. 1–15, 2018. doi: 10.1145/3190508.3190538

[27] A. Dorri, S. S. Kanhere, and R. Jurdak, "Towards an optimized blockchain for IoT," in Proc. 2nd Int. Conf. on Internet-of-Things Design and Implementation (IoTDI '17), pp. 173–178, 2017. doi: 10.1145/3054977.3055003

[28] A. Dorri, S. S. Kanhere, R. Jurdak, and P. Gauravaram, "LSB: A lightweight scalable blockchain for IoT security and anonymity," Journal of Parallel and Distributed Computing, vol. 134, pp. 180–197, 2019. doi: 10.1016/j.jpdc.2019.08.005

[29] A. Reyna, C. Martín, J. Chen, E. Soler, and M. Díaz, "On blockchain and its integration with IoT: Challenges and opportunities," Future Generation Computer Systems, vol. 88, pp. 173–190, 2018. doi: 10.1016/j.future.2018.05.046

[30] X. Liang, S. Shetty, D. Tosh, C. Kamhoua, K. Kwiat, and L. Njilla, "ProvChain: A blockchain-based data provenance architecture in cloud environment with enhanced privacy and availability," in Proc. 17th IEEE/ACM Int. Symp. on Cluster, Cloud and Grid Computing (CCGrid '17), pp. 468–477, 2017. doi: 10.1109/CCGRID.2017.8

[31] D. V. Medhane, A. K. Sangaiah, M. S. Hossain, G. Muhammad, and J. Wang, "Blockchain-enabled distributed security framework for next-generation IoT: An edge cloud and software-defined network-integrated approach," IEEE Internet of Things Journal, vol. 7, no. 7, pp. 6143–6149, Jul. 2020. doi: 10.1109/JIOT.2020.2977196

[32] M. S. Rahman, M. A. P. Chamikara, I. Khalil, and A. Bouras, "Blockchain-of-blockchains: An interoperable blockchain platform for ensuring IoT data integrity in smart city," Journal of Industrial Information Integration, vol. 30, art. 100408, 2022. doi: 10.1016/j.jii.2022.100408

[33] W. Shi, J. Cao, Q. Zhang, Y. Li, and L. Xu, "Edge computing: Vision and challenges," IEEE Internet of Things Journal, vol. 3, no. 5, pp. 637–646, 2016. doi: 10.1109/JIOT.2016.2579198

[34] M. Satyanarayanan, "The emergence of edge computing," Computer, vol. 50, no. 1, pp. 30–39, 2017. doi: 10.1109/MC.2017.9

[35] R. Roman, J. Lopez, and M. Mambo, "Mobile edge computing, Fog et al.: A survey and analysis of security threats and challenges," Future Generation Computer Systems, vol. 78, pp. 680–698, 2018. doi: 10.1016/j.future.2016.11.009

[36] A. A. Süzen, B. Duman, and B. Şen, "Benchmark analysis of Jetson TX2, Jetson Nano and Raspberry PI using Deep-CNN," in Proc. 2020 Int. Congr. on Human-Computer Interaction, Optimization and Robotic Applications (HORA), 2020. doi: 10.1109/HORA49412.2020.9152915

Chapter 3 — Methodology

4,979 words · source chapter3_methodology.md

Chapter 3: Methodology

3.1 Overview of Proposed Framework

This chapter describes the methodology adopted to design and implement a multi-layered security framework for an edge-based smart parking detection system. The proposed framework integrates three distinct layers: a computer vision layer for parking occupancy detection, an edge-local processing layer with data minimisation on the integrity path, and a lightweight, blockchain-inspired hash chain layer for video stream integrity verification. Together, these layers form a cohesive system deployed on an NVIDIA Jetson Nano developer kit, a resource-constrained edge computing device capable of real-time inference and local data processing.

The choice of an edge deployment follows the established rationale for edge computing: placing computation near the data source to reduce response time, bandwidth cost and exposure of raw data [33], [34]. The primary motivation for the security framework itself arises from the vulnerability of conventional parking detection systems to data manipulation. In existing systems, video feeds and detection results are transmitted to cloud servers without integrity guarantees, making them susceptible to adversarial attacks such as frame injection, replay attacks, and metadata tampering. These are documented rather than hypothetical threats: systematic weaknesses in deployed CCTV and IP-camera infrastructure are well catalogued [8], and injection of forged video streams has been demonstrated against commercial cloud-connected surveillance products [9]. The smart parking literature, by contrast, measures detection accuracy extensively but does not generally address the integrity of the stored record [1], [2]. The proposed framework addresses these vulnerabilities by anchoring each captured frame to a cryptographic hash chain, so that modifications which leave the chain internally inconsistent are detectable. The qualification matters and is carried throughout this thesis: an adversary who recomputes the affected hashes after tampering produces a self-consistent chain that local verification cannot distinguish from a legitimate one (§5.2.6, §5.2.7), and the chain binds the detection pipeline's output rather than the configuration that produced it (§3.1.1).

Figure 3.1 illustrates the overall system architecture and the flow of data across all three layers.

RTSP Camera (IP Camera)
        |
        v
[Layer 1: Canny Edge Detection]
  - Capture frame every 5 seconds
  - Define ROI polygons per parking slot
  - Detect: empty / occupied
        |
        v
[Layer 2: Edge-Local Processing + Data Minimisation]
  - Encode frame to JPEG (locally)
  - Compute SHA-256 frame hash
  - Store raw frame on Jetson Nano
        |
        v
[Layer 3: Lightweight Hash Chain]
  - Build Block (hash + detection result + metadata)
  - Append to local hash chain (SQLite)
  - Auto-checkpoint to AWS DynamoDB every 10 blocks
  - Upload detection status + hash to cloud (checkpoint path: hash + status only)

Figure 3.1: Three-layer system architecture of the proposed parking security framework.

3.1.1 Threat Model

To scope the security guarantees evaluated in this thesis, an explicit threat model is defined. The adversary capabilities below follow the edge security literature, which identifies the physical accessibility of edge nodes and their limited capacity for protective measures as defining characteristics of the paradigm [35]. An edge device installed in a car park is not housed in a controlled facility, so local or physical access is treated here as a realistic assumption rather than a worst case. The model assumes an adversary with the following capabilities:

• Read/write access to stored artefacts on the edge device: the adversary can read, modify, delete, or insert entries in the local hash chain database (chain.db) and in locally stored JPEG frames, as if they had gained filesystem access to the Jetson Nano (e.g., through physical access, a compromised SSH credential, or an unpatched local service).
• Network man-in-the-middle (MITM) capability: the adversary can intercept or modify data in transit between the edge device and the cloud (e.g., forged or replayed status updates), within the bounds of standard TLS-protected AWS SDK connections.
• Physical camera substitution or obstruction: the adversary can substitute the live RTSP feed with a pre-recorded or static feed, or physically obstruct/decorate the camera's field of view. This capability is only partially evaluated, and the gap is stated here rather than left implicit. E8 tests substitution by byte-identical frame replay, which the repeated-hash scan detects; a substituted feed that re-encodes each frame (a display showing a static image, or a re-encoded loop) produces differing hashes and is not detected by any mechanism evaluated in this thesis (§5.2.8). E10, which would assess physical obstruction, has not yet been conducted (n = 0, §5.2.10). Physical camera substitution is therefore in scope as an adversary capability but remains substantially unevaluated.

The following are explicitly out of scope for this thesis and are not defended against by the proposed framework:

• Independent compromise of the AWS account or operator credentials — that is, an adversary who obtains cloud write access by means other than compromising the edge device, such as a leaked operator access key or a misconfigured account policy. Securing operator-side credential management is treated as a standard cloud-security operational concern, not a research contribution of this work.
• Compromise of the running detection process itself. If an adversary gains the ability to execute arbitrary code within the running parking_detector.py process (e.g., via a supply-chain attack on a Python dependency), they could forge valid blocks before they are hashed, since the hash chain protects data after capture, not the integrity of the capture pipeline itself.
• Denial-of-service attacks against the RTSP camera, the Jetson Nano, or AWS availability.

A qualification on the boundary between these two scopes. The in-scope and out-of-scope capabilities above are not fully separable in the system as deployed. The edge device must hold IAM credentials permitting PutItem on the parking_blockchain table in order to upload checkpoints at all, so an adversary who achieves the in-scope capability of device write access thereby also inherits cloud write access — not through an independent compromise of the AWS account, but as a direct consequence of a capability this model admits. Combined with two implementation properties (checkpoint uploads are unconditional overwrites, and the anchored_at field is device-generated; see §3.5.6), this means the cloud anchor as evaluated in this thesis provides no guarantee against the very adversary the model places in scope. This is stated here rather than deferred because it materially qualifies the results reported in Chapter 5: the analysis in §5.4.3 and the hardening specified in §5.4.5 follow directly from it. Making the boundary hold requires the checkpoint store to be append-only under a service identity the device does not possess, and the anchoring time to be server-derived; both are specified in §5.4.5 and are the immediate next step for this work.

This threat model directly motivates the ten tamper-detection experiments (E1–E10, §3.6.3): each experiment instantiates one concrete attack within the in-scope capabilities above, applied to a copy of the hash chain, allowing the detection rate and latency of the proposed framework to be measured against a realistic adversary rather than an unbounded one.

3.2 Hardware and Software Environment

3.2.1 Edge Device

The system runs on an NVIDIA Jetson Nano Developer Kit, a single-board computer designed for edge AI applications. Table 3.1 summarises the hardware specifications of the device used in this study.

Table 3.1: Hardware specifications of the NVIDIA Jetson Nano Developer Kit.

The Jetson Nano was selected for its balance between computational capability and power efficiency, making it suitable for continuous long-term deployment in a parking facility environment.

3.2.2 Camera

An IP camera with RTSP (Real-Time Streaming Protocol) support is used to capture the parking lot footage. The camera is mounted at an elevated angle to provide a bird's-eye view of the monitored parking area. The RTSP stream is accessed at a resolution of 1020×600 pixels, which provides sufficient detail for edge detection while minimising processing overhead on the Jetson Nano.

3.2.3 Cloud Infrastructure

AWS (Amazon Web Services) is used as the cloud backend for the system. Two DynamoDB tables are provisioned:

• parking_frames — stores detection status, frame hash, block index, and S3 URI per captured frame.
• parking_blockchain — stores cloud anchor checkpoints (block hash, frame hash, timestamp) for integrity verification.

An S3 bucket (parking-detection-frames) stores the JPEG frames uploaded from the Jetson Nano.

3.2.4 Software Stack

Table 3.2: Software dependencies and their roles in the system.

3.3 Layer 1 — Parking Occupancy Detection

3.3.1 Region of Interest (ROI) Definition

Before the detection system can operate, the parking slots within the camera's field of view must be defined. This is accomplished using a custom interactive tool (roi_selector.py) that displays a live frame from the RTSP stream and allows the operator to manually trace polygon boundaries around each parking slot using mouse clicks.

The ROI definition process is as follows:

1. The operator runs roi_selector.py, which connects to the RTSP stream and captures a single reference frame.
2. The operator left-clicks to mark corner points of each parking slot polygon.
3. A right-click completes the current polygon and begins the next.
4. Upon pressing s, all polygon coordinates are saved to rois.json.

A total of 14 parking slots were defined for this study. Each polygon is stored as a list of (x, y) coordinate pairs in JSON format. This approach allows ROI definitions to be updated whenever the camera position changes without modifying the detection code.

3.3.2 Canny Edge Detection

The Canny edge detector [4] was selected as the occupancy detection algorithm. Canny derived the operator from an explicit optimisation of three criteria — good detection, good localisation, and a single response to a single edge — yielding the standard pipeline of Gaussian smoothing, gradient computation, non-maximum suppression and hysteresis thresholding. It is used here as a deliberately minimal carrier application rather than as a contribution to detection accuracy; as noted in §2.2.4, convolutional inference has been demonstrated on camera-class hardware [6], so no claim is made that edge resource constraints compel a classical method. The specific reasons for its selection are:

1. Computational efficiency — Canny operates on CPU without requiring GPU acceleration, leaving the Jetson Nano GPU available for other tasks.
2. Noise suppression — the Gaussian smoothing step in Canny suppresses high-frequency sensor noise, which would otherwise produce spurious edge responses. This should not be overstated as robustness to illumination: smoothing attenuates noise, not variation in scene lighting, and Canny's response remains sensitive to changes in contrast and shadow. Lighting sensitivity is reported as a limitation in §5.4.5, and the pixel-count threshold required empirical recalibration (§3.3.2) partly for this reason.
3. No training data required — unlike deep learning approaches (e.g., YOLO), Canny does not require a labelled dataset, making it practical for rapid deployment.

The detection process for each frame is as follows:

1. For each ROI polygon, a binary mask is applied to isolate the parking slot region.
2. The masked region is converted to grayscale.
3. Canny edge detection is applied with Threshold1 = 100 and Threshold2 = 200.
4. The number of non-zero (edge) pixels within the mask is counted.
5. If the edge pixel count exceeds 300, the slot is classified as occupied; otherwise, it is classified as empty.

The threshold values (100, 200) and the pixel count threshold were determined empirically through calibration trials on the target parking area. The pixel count threshold was initially set at 500 but was revised downward to 300 during deployment after observing that the higher threshold missed vehicles that produced fewer detectable edges under certain lighting and occlusion conditions.

A known defect in the operation order. Steps 1–3 above apply the ROI mask before Canny is executed. Because Canny computes gradients over a neighbourhood [4], the hard boundary introduced by the mask is itself detected as an edge, and those perimeter pixels are then counted by step 4 as though they were scene content. The correct order is to run Canny over the unmasked image and apply the mask to the resulting edge map. This is a correctness fault rather than a tuning choice, and it is reported here as part of the methodology because it affects the interpretation of every Layer 1 verdict in this thesis. Its magnitude was measured directly, and the measurement, its effect on the recorded verdicts, and the corrected implementation are reported in Chapter 5. Layer 3 results are unaffected: the hash chain records whatever Layer 1 reports, faithfully, irrespective of whether that report is correct.

# Simplified detection logic (from parking_detector.py)
for polygon in rois:
    mask = np.zeros(frame.shape[:2], dtype=np.uint8)
    cv2.fillPoly(mask, [np.array(polygon, np.int32)], 255)
    masked = cv2.bitwise_and(frame, frame, mask=mask)
    gray   = cv2.cvtColor(masked, cv2.COLOR_BGR2GRAY)
    edges  = cv2.Canny(gray, 100, 200)
    status = "occupied" if np.count_nonzero(edges) > 300 else "empty"

3.3.3 Frame Capture Strategy

Frames are captured from the RTSP stream at a fixed interval of 5 seconds rather than only upon status change. This design decision was made for the following reasons:

• Continuous integrity monitoring: capturing every 5 seconds eliminates temporal gaps in the hash chain. A status-change-only approach would leave potentially long intervals during which the video feed could be substituted without detection.
• Sufficient responsiveness: a 5-second interval is adequate for detecting parking events, as vehicles typically take 10–30 seconds to enter or exit a slot.
• Predictable chain growth: fixed-interval capture ensures the hash chain grows at a consistent rate of approximately 720 blocks per hour, which facilitates performance benchmarking.

3.4 Layer 2 — Edge-Local Processing with Data Minimisation

3.4.1 Data Minimisation on the Integrity Path

Layer 2 applies data minimisation to the integrity path: parking occupancy is classified locally on the Jetson Nano, and the integrity mechanism (Layer 3's hash chain and its DynamoDB checkpoints) uploads only derived data — no visual content is required to verify integrity. The data uploaded on this integrity path are limited to:

• SHA-256 hash of the JPEG-encoded frame
• Detection status (empty/occupied) for each parking slot
• Timestamp and block index

Frame images themselves are uploaded to cloud storage over a separate, configurable operational channel (§4.3.2, UPLOAD_FRAMES_TO_S3), enabled in this deployment to support the live dashboard, audit, and ground-truth labelling; the integrity guarantees are independent of it and hold identically when it is disabled.

This design means that the integrity checkpoint path stored in DynamoDB carries no visual content, so no raw video footage can be reconstructed from the checkpoint records alone. When the operational frame-upload channel is enabled, the frame images themselves reside in a private, access-controlled S3 bucket under the operator's control (§4.3.2).

3.4.2 Frame Hashing

Upon capture, each frame is JPEG-encoded and its SHA-256 hash is computed locally before any transmission:

_, buf      = cv2.imencode(".jpg", frame)
frame_bytes = buf.tobytes()
frame_hash  = hashlib.sha256(frame_bytes).hexdigest()

The resulting hash is a 64-character hexadecimal string that uniquely identifies the frame content. Any modification to the frame — even a single pixel — produces a completely different hash value. This makes frame modification detectable provided the stored hash is not itself updated to match; an adversary with write access to the chain who recomputes the affected hashes defeats this check by construction, which is why the cloud anchor exists and why its current limitations (§3.5.6) matter.

3.5 Layer 3 — Lightweight Hash Chain for Integrity Verification

This layer is the primary focus of evaluation in this thesis. A lightweight hash chain is implemented to provide cryptographic evidence of the integrity and ordering of captured parking frames.

The construction itself is not novel, and this is stated explicitly rather than implied. Binding records into a tamper-evident sequence by including each record's hash in its successor is the linking scheme of Haber and Stornetta [12], published in 1991, and the periodic publication of a compact digest to an external witness is due to Bayer et al. [13] in 1993. Replacing distributed consensus with a centrally managed hash-linked ledger for resource-constrained devices is likewise an established design position [27], [28]. The contribution claimed here is therefore evidential rather than mechanical: the systematic measurement of how this well-understood construction behaves on constrained edge hardware under adversarial conditions, and the explicit determination of the boundaries at which its guarantees fail (§2.7.2).

3.5.1 Block Structure

Each block in the chain encapsulates the following fields:

Table 3.3: Fields of a single block in the hash chain.

The block_hash is computed as follows:

payload = json.dumps({
    "block_index":      self.block_index,
    "timestamp":        self.timestamp,
    "frame_hash":       self.frame_hash,
    "detection_result": self.detection_result,
    "device_id":        self.device_id,
    "previous_hash":    self.previous_hash,
}, sort_keys=True).encode()

self.block_hash = hashlib.sha256(payload).hexdigest()

Using sort_keys=True ensures that the JSON serialisation is deterministic regardless of dictionary insertion order, guaranteeing consistent hash values.

3.5.2 Genesis Block

The chain is initialised with a genesis block (block index 0), which serves as the immutable anchor of the chain. Its previous_hash and frame_hash are set to a string of 64 zeros, signifying the start of the chain. No frame data is associated with the genesis block.

3.5.3 Chain Construction

For each captured frame, a new block is appended to the chain:

1. Compute frame_hash = SHA-256(JPEG bytes)
2. Retrieve previous_hash from the tip of the chain
3. Instantiate a new Block with all fields
4. Compute block_hash = SHA-256(all fields)
5. Append to in-memory chain
6. Persist to SQLite database (chain.db)
7. If block_index % 10 == 0, upload checkpoint to DynamoDB

3.5.4 Chain Verification

The integrity of the hash chain is verified by iterating over all blocks and checking two conditions for each block i:

1. Self-integrity: block.block_hash == SHA-256(block fields) — detects any modification to the block's own content.
2. Chain linkage: block.previous_hash == chain[i-1].block_hash — detects deletion, insertion, or reordering of blocks.

If either condition fails, the verification returns (False, i, elapsed_ms), where i is the index of the first compromised block. This O(n) verification algorithm is empirically characterised in Experiment P3.

3.5.5 SQLite Persistence

All blocks are persisted to a local SQLite database (chain.db) via the ChainStorage class. SQLite was selected over alternative storage solutions for the following reasons:

• Zero configuration — no server required; the database is a single file.
• Low overhead — minimal CPU and RAM consumption on the resource-constrained Jetson Nano.
• Durability — blocks survive system reboots and power interruptions.
• Portability — the database file can be transferred to a PC for offline analysis.

3.5.6 Cloud Anchor via AWS DynamoDB

To extend the integrity guarantee beyond the local device, a cloud anchor mechanism is implemented. Every 10 blocks, the current block's hash is uploaded to AWS DynamoDB as a checkpoint. This serves two purposes:

1. Tamper evidence across reboots (intended): if an attacker modifies chain.db, the cloud checkpoints would not match the reconstructed chain. As implemented this does not hold against the adversary defined in §3.1.1, for a reason independent of the timestamp issue below: upload_checkpoint() issues an unconditional put_item, so an attacker who inherits the device's IAM credentials can overwrite the checkpoints to match the rewritten chain. Both properties must be fixed before this purpose is achieved (§5.4.3, §5.4.5).
2. Timestamp anchoring: the DynamoDB record includes an anchored_at field recording when the checkpoint was uploaded, intended as a time reference independent of the block's own self-reported timestamp field.

The cloud verification process (verify_against_cloud()) compares every locally stored checkpoint block against its DynamoDB record and reports any hash mismatches.

Implementation qualification. The anchored_at value is generated on the edge device (datetime.utcnow() in CloudAnchor.upload_checkpoint()) and written as an ordinary item attribute; DynamoDB does not timestamp items on the server side automatically. In the configuration evaluated in this thesis, anchored_at is therefore not independent of an adversary who controls the device, and the second purpose above holds only against an adversary who can alter the local chain but not the upload path. Obtaining a genuinely device-independent time reference requires deriving it from the cloud service rather than the client — for example the server-set LastModified attribute of an object written to Amazon S3, the ApproximateCreationDateTime field of a DynamoDB Streams record, or an AWS CloudTrail event time. The consequences of this limitation for the replay results are analysed in §5.2.6, and the corresponding hardening is set out in §5.4.5.

This limitation should be read against the standard the literature has long established. Haber and Stornetta [12] set the objective that back-dating and forward-dating remain infeasible even with the collusion of a time-stamping service, and RFC 3161 [23] specifies the institutional form of that requirement: a time reference issued and attested by a party distinct from the entity whose data is timestamped. Where the time value is generated by the same device whose records are under audit, there is no second party to the timestamp at all. Similarly, the anchoring design here follows the periodic-publication principle of Bayer et al. [13], but does not yet meet the enforcement standard demonstrated by Certificate Transparency [21], in which append-only behaviour is not requested of the log operator but made externally verifiable by independent monitors. That distinction is what makes a client-applied conditional write insufficient: any holder of the write credential may simply omit it, so enforcement must be a property of the storage service rather than of the client. The hardening specified in §5.4.5 follows this pattern directly.

3.6 Experiment Design

3.6.1 Statistical Framework

All experiments in this study use n ≥ 30 trials. Where the measured quantity is continuous and genuinely variable — detection and verification latencies, hash throughput, CPU and RAM usage — this sample size allows the sampling distribution of the mean to be treated as approximately normal by the Central Limit Theorem, supporting parametric tests and 95% confidence intervals.

Two qualifications are necessary, because "n = 30 independent trials" would overstate the design.

First, several experiments are repeated-measures designs at fixed conditions rather than 30 independent draws. E2 and E3, for example, use three fixed tamper positions (beginning, middle, end) with 10 repetitions each; the target indices are fixed by a seeded generator (random.seed(42)) so that runs are reproducible. The within-position standard deviations of 0.15–0.29 ms reported in §5.2.2 therefore quantify timing jitter on a deterministic operation, not sampling variability across attack positions. Latency results are accordingly interpreted as "30 repetitions of a deterministic operation across three conditions", and the between-position differences — which are large and systematic — are the substantive finding rather than the pooled mean.

Second, the detection outcome of a cryptographic check is deterministic, not stochastic: given the same tampered chain, verify_chain() returns the same verdict every time. Repetition cannot estimate a detection probability that has no sampling variability, and the CLT is not what justifies reporting these proportions. Detection rates are therefore reported with Wilson score intervals purely to express the uncertainty that remains from having tested a finite number of conditions, and the negative-control arm (§5.2.11) rather than the sample size is what makes those rates interpretable.

All results are reported in the following format:

Mean = X unit (SD = Y, 95% CI [A, B], n = 30)

where the confidence interval is computed as:

$CI = \bar{x} \pm 1.96 \times \frac{s}{\sqrt{n}}$

3.6.2 Baseline Chain

Before each tamper detection trial (E1–E9), a clean baseline chain of 1,000 blocks is constructed in an isolated temporary database by build_test_chain() in tamper_simulator.py. Each block is appended with a synthetic frame payload of random bytes (os.urandom), so the chain has the correct structure — six hashed fields, genesis block, forward linkage — without requiring 83 minutes of live capture per trial. A separate script, capture_baseline.py, exists to build a baseline chain from the live RTSP stream at the 5-second capture interval, but it was not used to produce the results reported in Chapter 5.

This choice is stated explicitly because it bounds what the tamper-detection results demonstrate. The hash chain operates over frame_hash values, and a SHA-256 digest of random bytes is indistinguishable from a digest of JPEG bytes for every operation the chain performs, so E1–E7 measure the integrity mechanism faithfully. It does, however, mean that no result in §5.2 is evidence about real video content — most consequentially for E8, whose repeated-hash scan relies on byte-identical frames that arise in synthetic chains only when deliberately inserted (§5.2.8).

3.6.3 Tamper Detection Experiments (E1–E10)

Ten tamper detection experiments are designed to evaluate the system's ability to detect nine categories of adversarial attack plus physical sensor spoofing. Each experiment applies a specific attack to a clean chain copy and measures the detection rate and detection latency.

Table 3.4: Summary of tamper detection experiments.

For each experiment, detection rate and 95% confidence interval are computed using the Wilson score interval, which is appropriate for proportion data:

$CI = \frac{\hat{p} + \frac{z^2}{2n} \pm z\sqrt{\frac{\hat{p}(1-\hat{p})}{n} + \frac{z^2}{4n^2}}}{1 + \frac{z^2}{n}}$

3.6.4 Performance Benchmark Experiments (P1–P4)

Four performance benchmarks characterise the computational overhead and long-term stability of the proposed system.

P1 — Security Overhead: A paired design is used in which 30 one-minute intervals are measured with and without the full security and upload path active. The independent variable is stated precisely because it is broader than the hash chain alone: the "with" condition enables JPEG encoding, SHA-256 hashing, hash chain append, S3 frame upload and DynamoDB checkpointing together. The measured cost is therefore that of the whole path, not of the chain in isolation — and since frame upload is a configurable operational feature (§3.4.1), part of the measured overhead is attributable to a component the integrity mechanism does not require. Isolating the chain would need a third arm (chain active, upload disabled), which was not run; this is noted as a limitation in §5.3.1. CPU usage (%), RAM consumption (MB), and frame rate (FPS) are recorded for each interval. A paired t-test is applied to test whether the overhead is statistically significant (α = 0.05). The target overhead threshold is less than 15% CPU.

P2 — Hash Throughput: The SHA-256 hashing throughput of the Jetson Nano is measured by hashing 1,000 simulated frames per iteration across 30 iterations. The target is to demonstrate that the hashing rate exceeds 100 hashes per second, confirming that the cryptographic layer does not introduce a processing bottleneck.

P3 — Verification Time Scaling: The chain verification time is measured across five chain lengths (100, 500, 1,000, 5,000, and 10,000 blocks) with 6 runs each (30 total). Linear regression is applied to the (chain length, verification time) pairs to demonstrate O(n) time complexity. An R² value of ≥ 0.95 is used as the criterion for confirming linear scaling.

P4 — 24-Hour Stability: The system is run continuously for 24 hours with samples collected every 48 minutes (30 samples total). CPU usage, RAM consumption, chain length, and chain validity are recorded at each sample point. Linear regression of RAM over time is used to detect memory leaks; a slope of less than 1 MB per sample is used as the stability criterion.

3.7 Summary

This chapter presented the methodology for a three-layer parking security framework deployed on an NVIDIA Jetson Nano. Layer 1 employs Canny edge detection with manually defined polygon ROIs for parking occupancy classification. Layer 2 applies edge-local processing with data minimisation on the integrity path, so that the integrity mechanism transmits only cryptographic hashes and detection results to the cloud, while frame-image upload to a private S3 bucket is a separate, configurable operational feature the framework does not depend on. Layer 3, the primary contribution of this thesis, implements a lightweight SHA-256 hash chain with SQLite persistence and AWS DynamoDB cloud anchoring to provide verifiable integrity guarantees over the parking video record.

The experiment design follows CLT-compliant methodology with n ≥ 30 trials per experiment, encompassing 10 tamper detection experiments (E1–E10) and 4 performance benchmarks (P1–P4), totalling a minimum of 420 independent measurements. Chapter 4 presents the implementation details of the system, followed by experimental results in Chapter 5.

Chapter 4 — Implementation

1,773 words · source chapter4_implementation.md

Chapter 4: Implementation

4.1 Overview

This chapter describes the implementation of the three-layer parking security framework on the NVIDIA Jetson Nano. The discussion covers the hardware setup, software configuration, implementation of each system component, AWS cloud integration, and the complete operational pipeline. Code excerpts are provided where relevant to illustrate key implementation decisions.

4.2 Hardware Setup

4.2.1 Jetson Nano Configuration

The NVIDIA Jetson Nano Developer Kit was configured with Ubuntu 18.04 LTS and Python 3.8. Remote access is enabled via SSH over a Tailscale VPN tunnel, allowing secure access from any network without exposing the device to the public internet. The device operates continuously (24/7) with the --restart unless-stopped Docker policy applied where applicable.

Network connectivity is provided via Wi-Fi, and the device is assigned the Tailscale IP address 100.90.53.23. All parking security scripts reside in the ~/parking_security/ directory with the following structure:

~/parking_security/
├── parking_detector.py       # Main detection + hash chain pipeline
├── blockchain.py             # Block, HashChain, ChainStorage
├── cloud_anchor.py           # AWS DynamoDB checkpoint
├── performance_monitor.py    # CPU/RAM/GPU monitoring
├── roi_selector.py           # Interactive ROI definition tool
├── rois.json                 # 14 parking slot ROI coordinates
├── tamper_simulator.py       # 6 attack simulation functions
├── run_tamper_experiments.py # E1–E7 experiment runner
├── run_advanced_experiments.py # E8–E10 experiment runner
├── benchmark_hash.py         # P2 hash throughput benchmark
├── benchmark_chain.py        # P3 verification scaling benchmark
├── run_P1_overhead.py        # P1 security overhead
├── run_P4_stability.py       # P4 24hr stability test
├── capture_baseline.py       # 1,000-frame baseline chain capture
├── run_all.py                # Master experiment runner
├── generate_report.py        # Chart generation
├── statistical_analysis.py   # Statistical functions
├── generate_master_table.py  # Master results table
├── setup_dynamodb.py         # DynamoDB table provisioning
├── smoke_test.py             # End-to-end pipeline verification
├── requirements.txt          # Python dependencies
├── data/                     # Experiment CSVs, chain.db
├── frames/                   # Locally stored JPEG frames
├── logs/                     # System and experiment logs
└── figures/                  # Generated chart PNGs

Figure 4.1: Directory structure of the parking security system.

4.2.2 Camera Installation

The IP camera is mounted at an elevated position overlooking the monitored parking area. The camera streams footage via RTSP at a resolution of 1020×600 pixels. The stream is accessible within the local network at:

rtsp://admin:<REDACTED>@10.207.200.224:554/stream1

The Jetson Nano connects to the RTSP stream using OpenCV's VideoCapture with the CAP_FFMPEG backend, which provides hardware-accelerated decoding on the Jetson platform.

4.3 AWS Cloud Setup

4.3.1 DynamoDB Table Provisioning

Two DynamoDB tables are created using setup_dynamodb.py. Both tables use on-demand (pay-per-request) billing mode, eliminating the need to provision fixed read/write capacity units.

Table creation is idempotent — running setup_dynamodb.py multiple times will not duplicate tables. The script waits for each table to reach ACTIVE status before proceeding.

4.3.2 S3 Bucket

An S3 bucket named parking-detection-frames stores the JPEG frames uploaded from the Jetson Nano. Frames are stored under the prefix frames/ with the filename format YYYYMMDD_HHMMSSffffff.jpg, where the filename encodes the capture timestamp with microsecond precision. This frame upload is a configurable operational feature (UPLOAD_FRAMES_TO_S3), enabled in this deployment to support the live dashboard, audit, and ground-truth labelling; the hash chain integrity mechanism does not depend on it and operates identically with it disabled, since integrity verification uses only the cryptographic hashes and detection metadata on the checkpoint path (§3.4.1).

4.3.3 AWS Credentials

AWS credentials are configured on the Jetson Nano using the AWS CLI:

aws configure

The credentials are stored in ~/.aws/credentials and accessed by the boto3 library at runtime. No credentials are hardcoded in any script.

4.4 ROI Definition

Before the detection system can operate, parking slot boundaries must be defined. This is performed once using roi_selector.py:

cd ~/parking_security
python3 roi_selector.py

The tool captures a reference frame from the RTSP stream and displays it in an interactive window. The operator traces each parking slot boundary by left-clicking corner points and right-clicking to complete each polygon. The completed ROIs are saved to rois.json.

A total of 14 parking slots were defined for this study. Figure 4.2 shows an example of the ROI polygon overlay on a reference frame.

[Insert screenshot of roi_selector.py with polygon overlays here]

The rois.json file stores coordinates in the following format:

[
  [[182, 191], [175, 232], [144, 235], [153, 195], [181, 191]],
  [[185, 229], [190, 190], [222, 184], [216, 221], [185, 227]],
  ...
]

4.5 Hash Chain Implementation

4.5.1 Block Dataclass

The Block dataclass (defined in blockchain.py) encapsulates all fields of a single chain entry. The block_hash field is automatically computed upon instantiation via __post_init__:

@dataclass
class Block:
    block_index:      int
    timestamp:        str
    frame_hash:       str
    detection_result: dict
    device_id:        str
    previous_hash:    str
    block_hash:       str = field(init=False)

    def __post_init__(self):
        self.block_hash = self.compute_hash()

    def compute_hash(self) -> str:
        payload = json.dumps({
            "block_index":      self.block_index,
            "timestamp":        self.timestamp,
            "frame_hash":       self.frame_hash,
            "detection_result": self.detection_result,
            "device_id":        self.device_id,
            "previous_hash":    self.previous_hash,
        }, sort_keys=True).encode()
        return hashlib.sha256(payload).hexdigest()

4.5.2 HashChain Class

The HashChain class manages the in-memory chain and coordinates block creation, persistence, and cloud checkpointing:

def add_block(self, frame_bytes: bytes, detection_result: dict) -> Block:
    fhash = hash_frame(frame_bytes)
    prev  = self.chain[-1].block_hash
    block = Block(
        block_index=len(self.chain),
        timestamp=datetime.utcnow().isoformat(),
        frame_hash=fhash,
        detection_result=detection_result,
        device_id=DEVICE_ID,
        previous_hash=prev,
    )
    self.chain.append(block)
    self.storage.save_block(block)

    # Auto-checkpoint to cloud every 10 blocks
    if self.cloud_anchor and block.block_index % CHECKPOINT_INTERVAL == 0:
        self.cloud_anchor.upload_checkpoint(block)

    return block

4.5.3 SQLite Persistence

The ChainStorage class persists all blocks to a local SQLite database. The schema consists of a single blocks table with seven columns corresponding to the Block fields. The block_index serves as the primary key, ensuring each block position is unique. Blocks are retrieved in ascending order by block_index during chain reload.

4.5.4 Chain Verification

The verify_chain() method performs O(n) verification with timing:

def verify_chain(self) -> Tuple[bool, Optional[int], float]:
    t0 = time.perf_counter()
    for i in range(1, len(self.chain)):
        curr = self.chain[i]
        prev = self.chain[i - 1]

        if curr.block_hash != curr.compute_hash():
            elapsed = (time.perf_counter() - t0) * 1000
            return False, i, elapsed

        if curr.previous_hash != prev.block_hash:
            elapsed = (time.perf_counter() - t0) * 1000
            return False, i, elapsed

    elapsed = (time.perf_counter() - t0) * 1000
    return True, None, elapsed

The method returns a three-tuple: a boolean validity flag, the index of the first compromised block (or None if valid), and the total verification time in milliseconds.

4.6 Main Detection Pipeline

4.6.1 System Initialisation

When parking_detector.py is launched, the following initialisation sequence is performed:

1. Required directories (frames/, logs/, data/) are created if absent.
2. A ChainStorage instance opens (or creates) chain.db.
3. A HashChain instance loads the existing chain from chain.db, or creates the genesis block if the chain is empty.
4. A CloudAnchor instance connects to the DynamoDB parking_blockchain table.
5. A PerformanceMonitor instance starts a background thread sampling CPU, RAM, and GPU metrics every 10 seconds.
6. ROI polygons are loaded from rois.json.
7. The RTSP stream is opened via cv2.VideoCapture.

4.6.2 Per-Frame Processing Loop

The main loop runs continuously until the operator presses q. For each captured frame, the following steps are executed:

1. Read frame from RTSP stream
2. Check elapsed time since last capture
   └─ If < 5 seconds: skip processing, check keyboard only
3. Detect parking status per ROI slot (Canny)
4. Encode frame to JPEG bytes
5. frame_hash = SHA-256(JPEG bytes)
6. block = chain.add_block(frame_bytes, detection_result)
   └─ Saves to chain.db
   └─ Auto-checkpoint to DynamoDB if block_index % 10 == 0
7. Upload JPEG frame to S3
8. Save detection status + hash to DynamoDB (parking_frames)
9. Draw ROI overlays on frame and display
10. PerformanceMonitor.tick() — update FPS counter

4.6.3 Keyboard Controls

The following keyboard controls are available during system operation:

4.6.4 Performance Monitoring

The PerformanceMonitor class runs as a daemon thread, sampling the following metrics every 10 seconds and appending rows to a timestamped CSV file:

The tegrastats utility is a Jetson-specific command-line tool that exposes hardware telemetry including GPU frequency and thermal sensor readings. It is invoked as a subprocess and its output is parsed using regular expressions.

4.7 Cloud Anchor Implementation

The CloudAnchor class (defined in cloud_anchor.py) implements two operations:

Upload checkpoint: uploads a minimal record to DynamoDB containing block_index, block_hash, frame_hash, timestamp, device_id, and anchored_at (server-side timestamp). Raw frame data is never included.

Verify against cloud: retrieves all stored checkpoints from DynamoDB and compares each block_hash against the corresponding local chain block. A mismatch indicates that either the local chain or the cloud record has been tampered with.

def verify_against_cloud(self, chain) -> dict:
    mismatches = []
    for block in chain.chain:
        item = self.table.get_item(
            Key={"block_index": str(block.block_index)}
        ).get("Item")
        if item and item["block_hash"] != block.block_hash:
            mismatches.append({
                "block_index": block.block_index,
                "local_hash":  block.block_hash,
                "cloud_hash":  item["block_hash"],
            })
    return {"verdict": "VALID" if not mismatches else "TAMPERED",
            "mismatches": len(mismatches)}

4.8 System Verification

Upon completion of the implementation, an end-to-end smoke test (smoke_test.py) was executed on the Jetson Nano to verify that all components function correctly without requiring a live camera connection. The test comprises 10 subtests covering module imports, block hashing, chain construction and verification, tamper detection, SQLite persistence, all six attack simulations, statistical functions, GPU monitoring, and the master table generator.

All 10 tests passed, confirming that the implementation is functionally complete and ready for experiment execution.

Smoke Test Results: 10/10 passed
All tests passed. Pipeline ready.

4.9 Summary

This chapter presented the complete implementation of the three-layer parking security framework. The hardware setup consists of a Jetson Nano connected to an IP camera over RTSP and to AWS cloud services via the boto3 SDK. The hash chain layer is implemented as a local, blockchain-inspired hash chain persisted in SQLite, with periodic checkpoints uploaded to DynamoDB for cloud-anchored integrity verification. The main detection pipeline integrates all three layers into a single continuous loop with keyboard controls for real-time chain inspection. Chapter 5 presents the results of the experimental evaluation (E1–E10, P1–P4).

Chapter 5 — Results and Discussion

8,431 words · source chapter5_results.md

Chapter 5: Results and Discussion

5.1 Overview

This chapter presents the results obtained from experiments conducted to evaluate the proposed three-layer parking security framework. The experiments are organised into three categories: tamper detection experiments (E1–E10), which assess the system's ability to detect adversarial attacks on the hash chain; performance benchmark experiments (P1–P4), which characterise the computational overhead and long-term operational stability of the system; and two control experiments (N1–N2) added to qualify the detection results — a negative-control arm establishing the false positive rate of each detection mechanism (§5.2.11), and a cost-equivalent baseline comparing the hash chain against direct per-frame anchoring (§5.4.4). Experiments E1–E9 and P1–P3 were conducted on the NVIDIA Jetson Nano with 30 trials per experiment. As set out in §3.6.1, these are repeated measures at fixed conditions rather than 30 independent draws, and the detection outcome of a cryptographic check is deterministic rather than stochastic; the Central Limit Theorem therefore justifies the parametric treatment of the continuous measures (latencies, throughput, resource usage) but not the detection proportions, which are interpreted per §3.6.1. Results are reported as mean ± standard deviation with 95% confidence intervals unless stated otherwise. Two interval conventions are used, chosen to match each result's underlying statistical test: single-sample and independent-sample continuous measures (e.g., E1–E9 latencies, P2, P3) use the normal-approximation interval \bar{x} \pm 1.96 \times s/\sqrt{n}; the paired-comparison measures in P1 use the t-distribution interval \bar{x} \pm t_{0.025,29} \times s/\sqrt{n} (with t_{0.025,29} = 2.045) to remain consistent with the paired t-test used to assess significance; detection-rate proportions (E1–E10) use the Wilson score interval.

Status note: P4 (stability) now reports the full 24-hour protocol described in Chapter 3 §3.6.4 (23.2 h between first and last samples), following an initial 4.85-hour pilot run reported alongside it for comparison. E10 (physical sensor spoofing) has not yet been conducted — a field session at the car park is scheduled (T3.3). §5.2.10 is marked accordingly and must be completed before this chapter is treated as final.

5.2 Tamper Detection Experiments

5.2.1 E1 — Frame Modification

Frame modification attacks were simulated by altering the stored frame hash to reflect a modified version of the original frame. Three sub-types were tested: single-pixel modification, ten-pixel modification, and Gaussian noise injection, with 10 trials each (n = 30 total).

Table 5.1: E1 Frame Modification Detection Results

Target: 100% detection rate — MET

Discussion: All 30 trials were detected with no false negatives, confirming that the hash chain's self-integrity check (recomputing block_hash and comparing against the stored value) catches any frame-hash substitution regardless of the magnitude of the underlying modification it represents. Because the attack is implemented at the hash level (the stored frame_hash is replaced with the hash of different random bytes rather than an actually re-encoded JPEG — see §3.5.1/§4.5.1), the three sub-types are cryptographically equivalent in terms of detectability; the differences in mean latency across sub-types (13.6–18.0 ms) reflect only where in the 1,000-block chain the tampered block happened to fall (verification is O(n) and stops at the first invalid block), not any difference in detection difficulty.

5.2.2 E2 — Frame Deletion

Frame deletion attacks were simulated by removing a block from the chain at three positions: beginning (block index 35), middle (block index 503), and end (block index 964), with 10 trials each (n = 30 total).

Table 5.2: E2 Frame Deletion Detection Results

Target: 100% detection rate — MET. As expected, deletions near the beginning of the chain are detected fastest (mean 1.69 ms) and deletions near the end are detected slowest (mean 38.49 ms), consistent with O(n) verification that halts at the first broken link.

Discussion: Deletion breaks the previous_hash linkage between the block preceding and the block following the deleted entry, which is caught deterministically on the first verification pass. The very low within-position standard deviations (0.15–0.29 ms) confirm that detection latency for a fixed deletion position is highly reproducible — latency is governed almost entirely by the position of the break in the chain, not by system-level noise.

5.2.3 E3 — Frame Injection

Frame injection attacks were simulated by inserting a fabricated block at three positions in the chain: beginning (index 29), middle (index 525), and end (index 967), with 10 trials each (n = 30 total).

Table 5.3: E3 Frame Injection Detection Results

Target: 100% detection rate — MET

Discussion: An injected block, even one whose own block_hash is internally self-consistent, breaks the chain linkage for the block that originally followed the injection point (its previous_hash no longer matches the injected block's block_hash), so injection is detected with the same mechanism and position-dependent latency profile as deletion (§5.2.2). The near-identical latency pattern across E2 and E3 (both governed by O(n) traversal to the break point) is expected given they share the same underlying verification algorithm.

5.2.4 E4 — Metadata Tampering

Metadata tampering attacks were simulated by modifying three block fields: timestamp, detection result, and device ID, with 10 trials each (n = 30 total).

Table 5.4: E4 Metadata Tampering Detection Results

Target: 100% detection rate — MET

Discussion: Because block_hash is computed over all block fields (block_index, timestamp, frame_hash, detection_result, device_id, previous_hash; see §3.5.1), any modification to a single field — however minor — invalidates the self-integrity check identically regardless of which field was altered. This is a direct structural consequence of the block hash design and explains why detection rate is uniformly 100% across all three sub-types.

5.2.5 E5 — Hash Record Alteration

Hash record alteration attacks were simulated by modifying the stored block_hash value using three methods: single-character change, random hash replacement, and adjacent hash swap, with 10 trials each (n = 30 total).

Table 5.5: E5 Hash Record Alteration Detection Results

Target: 100% detection rate — MET

Discussion: Direct tampering with the stored block_hash is the most fundamental attack against the hash chain's self-integrity mechanism, and — as expected by construction — is detected with certainty: any stored block_hash that does not equal the recomputed hash of its own fields is flagged, whether the alteration is a single character, a full random replacement, or a swap with an adjacent block's hash (the swap still fails because block_hash is bound to that specific block's other fields).

5.2.6 E6 — Replay Attack

Replay attacks were simulated across four scenarios with varying combinations of original/updated timestamps and original/recomputed hashes (n = 30 total: Scenario A = 8, B = 8, C = 7, D = 7).

Table 5.6: E6 Replay Attack Detection Results

Target: >95% detection rate — NOT MET. Combined detection rate of 53.3% falls substantially short of the target.

Discussion: This is the weakest result in the tamper-detection suite, and its cause is fully explained by the two-part local verification algorithm (§3.5.4, §4.5.4): verify_chain() checks only (1) self-integrity — whether a block's stored block_hash equals the hash recomputed from its own fields — and (2) chain linkage — whether a block's previous_hash equals the preceding block's block_hash. In Scenarios A and B, the replayed block retains its original block_hash while its block_index and previous_hash are updated to append it at the tip of the chain; this breaks self-integrity (the stored hash no longer matches the new field values) and is therefore always detected (16/16 across A+B). In Scenarios C and D, the attacker recomputes block_hash after modifying the block, producing a block that is internally self-consistent and correctly linked — indistinguishable, by local verification alone, from a legitimately appended block. These scenarios are therefore never detected locally (0/14 across C+D), and Scenario D (updated timestamp + recomputed hash) represents a fully successful replay against the local hash chain in isolation.

This result is not a flaw unique to this implementation; it is an inherent limitation of any purely local, content-addressed hash chain, which has no mechanism to verify when a block was genuinely created versus when it was replayed — timestamps are self-reported fields, not independently verified events. Closing it requires a time reference the attacker does not control, which is the role the cloud anchor (§3.5.6) is intended to play.

An important correction to that argument as currently implemented. The anchored_at value stored with each DynamoDB checkpoint is generated on the edge device by CloudAnchor.upload_checkpoint(), not by the cloud service (§3.5.6). It is therefore not independent of an adversary who holds the device-write capability that the threat model (§3.1.1) places in scope: such an adversary can alter the local chain, re-upload the affected checkpoints, and set anchored_at to any value. Against the adversary this thesis defines, the anchor as deployed consequently provides no independent timestamp evidence, and Scenarios B and D are not recoverable by the mechanism described above. This is a limitation of the evaluated configuration rather than of anchoring as an approach: a server-derived anchoring time (§3.5.6) placed in an append-only checkpoint store would restore the property, and is specified as required hardening in §5.4.5. Until that hardening is implemented and re-evaluated, the honest statement of this result is that E6 Scenarios C and D are undetected, and no compensating mechanism in the current system detects them — 53.3% is the framework's replay detection rate as built, not a local-only figure that cloud verification would improve. Hardening local detection of Scenario C/D-style replays (e.g., via a monotonic sequence counter or per-session nonce independent of block_index) is identified as future work (§6.4).

5.2.7 E7 — Chain Rewrite Attempt

Chain rewrite attacks were simulated by rewriting K blocks from the end of a 1,000-block chain, with 6 trials each for K = 10, 50, 100, 500, 1,000 (n = 30 total).

Table 5.7: E7 Chain Rewrite Time Results

Linear Regression (Rewrite Time vs K):

Target: Rewrite time < 1,000 ms for K = 10 — MET by three orders of magnitude (0.49 ms). Local detection rate: 0% by design (see Discussion).

Discussion: The 0/30 local detection rate is expected and is not a failure of the hash chain design — it demonstrates the fundamental limit of self-verification against an adversary with write access to the entire chain (in scope under the threat model, §3.1.1). An attacker who can rewrite blocks and their hashes can trivially reconstruct an internally consistent chain: attack_chain_rewrite() recomputes each block's previous_hash and block_hash sequentially from the point of tampering onward, so verify_chain() — which only checks internal consistency — passes on the rewritten chain (post-rewrite verify time ≈ 38.7–39.4 ms, indistinguishable from a clean chain of the same length). This is the central motivation for the cloud anchor mechanism (§3.5.6): because checkpoints are uploaded to an independent DynamoDB table at the time each block was originally created, a rewritten chain's blocks will no longer match their corresponding cloud-anchored block_hash values, and verify_against_cloud() will report a mismatch even though local verify_chain() reports the chain as valid. The linear growth in rewrite time (0.039 ms/block) — consistent with the P3 verification-time slope of 0.040 ms/block (§5.3.3), as both operations perform one SHA-256 computation per block — means that rewriting a large historical span remains computationally cheap on this hardware (≈ 40 ms for 1,000 blocks), reinforcing that computational cost alone is not a meaningful deterrent at this scale and that cloud anchoring, not rewrite latency, is what provides the actual security guarantee against this attack class.

5.2.8 E8 — Feed Substitution

Feed substitution attacks were simulated by replacing the last 20 frames with repeated identical hashes, across three time periods: morning, afternoon, and night (10 trials each, n = 30 total).

Table 5.8: E8 Feed Substitution Detection Results

Target: >90% detection rate — MET

Discussion: The last 20 frames of each 1,000-block chain were substituted with a repeated identical frame_hash, simulating a static or replayed camera feed. Detection is performed by a repeated-hash frequency scan (run_advanced_experiments.py, run_E8()): the algorithm counts occurrences of each distinct frame_hash across the chain and flags the chain as suspicious whenever any hash value repeats more than 5 times (threshold max_repeat > 5); all 30 trials produced a max_repeat of 20, far exceeding this threshold. This scan is independent of, and not caught by, verify_chain()'s self-integrity/linkage checks — a substituted feed with identical repeated hashes still produces a structurally valid, correctly self-consistent chain. The reported "latency" column is therefore not the repeated-hash scan's own runtime, but the elapsed time of the subsequent full-chain verify_chain() pass run alongside it for logging purposes (≈ 39 ms, consistent with traversing a full 1,000-block chain per P3's scaling result, §5.3.3). The uniform detection across all three simulated time periods indicates the mechanism is time-of-day independent, as expected since the attack is purely hash-pattern-driven.

Scope of this result. Because frame_hash is a SHA-256 digest of the JPEG-encoded frame bytes, two frames produce the same frame_hash only if they are byte-identical. This experiment therefore measures detection of exact frame replay — an adversary re-submitting the same encoded frame repeatedly, which is what a naive looped or frozen feed produces. It does not measure detection of a visually static feed that is still being freshly encoded: in live operation, successive frames of an unchanging scene differ in sensor noise and JPEG quantisation, so their digests differ and max_repeat would not rise. An adversary who substitutes the camera with a display showing a static image, or who re-encodes a looped recording rather than replaying identical bytes, would evade this particular scan while remaining within the in-scope capability of feed substitution (§3.1.1). The 100% figure reported here should accordingly be read as complete detection of byte-identical replay under the synthetic chain construction used in E1–E7 (§3.6.2), not as a general feed-substitution detection rate. Detecting perceptually rather than cryptographically repeated content would require a perceptual digest (e.g. a perceptual hash with a Hamming-distance threshold) in place of, or alongside, the cryptographic frame hash, and is identified as future work (§6.4).

5.2.9 E9 — Timestamp Manipulation

Timestamp manipulation attacks were simulated by altering block timestamps in three ways: shifting forward 24 hours, shifting backward 24 hours, and setting a random historical date, with 10 trials each (n = 30 total).

Table 5.9: E9 Timestamp Manipulation Detection Results

Target: >95% detection rate — MET

Discussion: E9's recorded detected outcome is produced by a timestamp-gap heuristic (run_advanced_experiments.py, run_E9()), which scans consecutive blocks and flags a manipulation whenever the gap between adjacent timestamps exceeds one hour — this is a purpose-built detector for temporal anomalies, distinct from verify_chain()'s self-integrity/linkage checks used throughout E1–E5. Because timestamp is also one of the fields covered by block_hash (§3.5.1), the attack is independently caught by self-integrity verification as well: the chain_valid column recorded alongside the gap-heuristic result is 0 (invalid) in all 30 trials, confirming that verify_chain() on its own would also flag every manipulated chain. E9 is therefore detected redundantly by two independent mechanisms, which is a stronger result than E4's timestamp sub-type (self-integrity only) and should not be attributed to self-integrity checking alone. This is a materially different (and easier) detection case than the replay scenarios in E6, where the attacker also recomputes block_hash after altering the timestamp, defeating self-integrity — but E9's gap heuristic would still not, on its own, catch the more sophisticated E6 Scenario D replay, since a single replayed block need not introduce a large timestamp gap relative to its neighbours.

5.2.10 E10 — Physical Sensor Spoofing

⚠️ NOT YET CONDUCTED. E10_physical_spoofing_template.csv currently contains only the trial template (6 object types × 5 repetitions = 30 planned trials) with no recorded data. A field session at the monitored car park is scheduled (see SONNET_TASK_PLAN.md T3.3) to physically place each object in an empty monitored slot and record the system's detection verdict. This section will be completed once that data is collected — do not report results for E10 until then.

Planned protocol: six object types will be tested with 5 trials each (n = 30 total): white poster, dark tape car outline, cardboard box, reflective surface, plastic bag, and tree branch debris.

Table 5.10: E10 Physical Spoofing False Positive Results (pending)

Note: E10 assesses Layer 1 detection algorithm limitations, not hash chain integrity. The hash chain records all detection results faithfully regardless of detection accuracy — this demonstrates that data integrity guarantees are independent of detection quality, i.e. even a false detection outcome is immutably and verifiably recorded rather than silently altered.

Discussion: (to be completed after the field session)

5.2.11 N1 — Negative Controls (False Positive Rate)

Every experiment in §5.2.1–§5.2.9 reports a true positive rate: how often each mechanism fires when tampering is present. Reported alone, such rates are uninterpretable — a detector that returned "tampered" unconditionally would also score 100% on all of them. A negative-control arm was therefore run to establish the corresponding false positive rate.

Thirty untampered 1,000-block chains were constructed by the same build_test_chain() routine used throughout E1–E7, and each of the three detection mechanisms exercised in this chapter was run against them without any attack applied. Any mechanism firing on such a chain constitutes a false positive.

Table 5.11: N1 Negative Control Results (n = 30 clean chains)

Target: 0% false positive rate — MET for all three mechanisms.

Discussion: No mechanism produced a single false positive across 30 clean chains. Two diagnostic columns recorded alongside the verdicts confirm the detectors were genuinely exercised rather than failing silently: observed_max_repeat was 1 in every trial (no frame_hash recurs in a chain built from independent random payloads, so the E8 scan had a real distribution to examine and correctly found nothing), and break_index was empty in every trial (the full chain was traversed to completion without encountering a mismatch). The detection rates reported in §5.2.1–§5.2.9 are therefore attributable to the mechanisms discriminating between tampered and untampered chains, not to an indiscriminate verifier.

A secondary consistency check emerges from the latency data. Verification of a clean 1,000-block chain averaged 39.93 ms, against the 39.35 ms measured independently for the same chain length in P3 (§5.3.3). The agreement is expected — an untampered chain offers no early exit, so verification must traverse every block — and the fact that two separately executed experiments converge on the same figure is corroborating evidence that both are measuring the intended quantity.

One limitation should be stated rather than glossed. build_test_chain() appends blocks in a tight loop, so adjacent timestamps in these control chains differ by well under a second and the largest observed gap was approximately 3 s, far below the 3,600 s threshold. The timestamp-gap control therefore demonstrates that the heuristic does not misfire, but on chains that could not plausibly have triggered it. This is not a defect of the control so much as a property inherited from the synthetic construction used by E9 itself: the control matches the experiment it qualifies, and no stronger claim is made from it. In deployment the capture interval is 5 s (§3.3.3), still two orders of magnitude below the threshold, so the same conclusion holds there — but a control run against genuinely long-interval data would be a stronger test and is left as future work.

5.2.12 Summary of Tamper Detection Results

Table 5.12: Summary of All Tamper Detection Experiments

FP Rate column is the false positive rate of the mechanism underlying each experiment, measured in N1 (§5.2.11) over 30 untampered chains; 95% CI [0.00, 11.35] in every case.

[Insert Figure 5.1 — Bar chart of detection rates E1–E9 here, generated via generate_report.py]

5.3 Performance Benchmark Experiments

5.3.1 P1 — Security Overhead

The security overhead introduced by the hash chain pipeline was measured using a paired design with 30 one-minute intervals each with and without the hash chain pipeline active.

Table 5.13: P1 Security Overhead Results

ΔRAM values are the change in resident memory measured over each one-minute interval (not absolute RAM footprint), which is why the without-hash-chain baseline is 0.00 MB; the metric captures memory growth attributable to the pipeline during the interval.

The FPS Overhead column is computed from raw (unrounded) per-trial data, not from the rounded means shown in this table; it will not exactly equal 19.95 − 14.64 due to display rounding.

Target: CPU overhead < 15% — MET (and not statistically distinguishable from zero). Paired t-test (α = 0.05).

Discussion: The CPU overhead result (mean −7.99%, 95% CI [−16.21, +0.22], p = 0.0562) is not statistically significant at α = 0.05 — note that the confidence interval spans zero, consistent with the non-significant p-value. The negative point estimate should not be interpreted as the hash chain pipeline reducing CPU usage; rather, the high trial-to-trial variance (SD = 22.0 percentage points, larger in magnitude than the mean itself) reflects background CPU load fluctuation on the Jetson Nano (e.g., from tegrastats sampling, RTSP decode jitter, or the OS scheduler) that swamps any consistent overhead the hash chain pipeline might introduce. The safest and most defensible conclusion is that no statistically significant CPU overhead was detected, which is itself a strong result for the framework's practicality on resource-constrained hardware. RAM overhead is negligible in absolute terms (+0.06 MB, CI spans zero) and also not statistically significant. The FPS reduction (−5.30 fps, 95% CI [−5.79, −4.82], p < 0.001) is statistically significant — the CI excludes zero — and practically the most relevant cost of the framework; most of this reduction is attributable to the per-frame JPEG encoding, SHA-256 hashing, and S3/DynamoDB upload calls in the main loop (§4.6.2) rather than the hash chain's verify/add_block operations alone, which §5.3.2 shows to be sub-millisecond at this chain length. A limitation of the P1 design should be stated alongside this: the toggled condition is the entire security and upload path — JPEG encoding, hashing, chain append, S3 upload and DynamoDB checkpointing together — not the hash chain in isolation (§3.6.4). Since frame upload to S3 is a configurable operational feature the integrity mechanism does not require (§3.4.1), an unknown share of the measured FPS cost belongs to a component that can be disabled without affecting integrity guarantees. Isolating the chain would require a third arm (chain active, upload disabled), which was not run; the figures below therefore bound the cost of the full path rather than attributing it. It is also important to note that this FPS metric measures the internal frame-processing rate of the benchmark loop (how fast the pipeline can process frames back-to-back), not the deployed system's capture cadence, which is fixed at one frame every 5 seconds (0.2 fps) by design (§3.3.3); since even the reduced 14.64 fps processing rate is roughly 73× faster than the 0.2 fps capture demand, this reduction has no effect on the deployed system's ability to keep up with its capture schedule.

5.3.2 P2 — Hash Throughput

SHA-256 hashing throughput was measured over 30 iterations of 1,000 frames each on the Jetson Nano.

Table 5.14: P2 Hash Throughput Results

Target: >100 hashes/second — MET, exceeded by two orders of magnitude.

[Insert Figure 5.2 — Histogram of hash throughput distribution here, generated via generate_report.py]

Discussion: At a sustained throughput of ~12,161 hashes/second (≈ 0.082 ms/hash), SHA-256 hashing is not a meaningful bottleneck relative to the 5-second frame capture interval (§3.3.3) — hashing a single frame consumes roughly 0.0016% of the time budget between captures. This confirms that the cryptographic layer (Layer 3) does not constrain the achievable frame rate; the FPS reduction observed in P1 (§5.3.1) is attributable to other pipeline stages (JPEG encoding, network I/O), not hashing.

5.3.3 P3 — Verification Time Scaling

Chain verification time was measured across five chain lengths (100, 500, 1,000, 5,000, 10,000 blocks) with 6 runs each (n = 30 total).

Table 5.15: P3 Verification Time by Chain Length

Table 5.16: P3 Linear Regression Results

Target: R² ≥ 0.95 to confirm O(n) scaling — MET (R² = 0.9998)

[Insert Figure 5.3 — Scatter plot with regression line here, generated via generate_report.py]

Discussion: The near-perfect linear fit (R² = 0.9998) confirms that verify_chain() scales as O(n), consistent with its single-pass sequential design (§3.5.4/§4.5.4). At 0.0399 ms/block, verifying the live production chain — which had exceeded 211,860 blocks as of 2026-04-29 (see §5.4.2) — would take approximately 8.5 seconds, a practically acceptable cost even at that scale, though this motivates the chain-archiving discussion in the Limitations (§5.4.5) for indefinitely long deployments.

5.3.4 P4 — Operational Stability

An initial 4.85-hour pilot run (2026-04-13, 07:46–12:37; 30 samples at 10-minute intervals) was conducted first to sanity-check the measurement protocol, followed by the full 24-hour protocol described in §3.6.4 (30 samples at a 48-minute interval, run window 2026-07-03 10:05 UTC → 2026-07-04 09:19 UTC, first-to-last-sample span 23.22 hours). The full-duration run was executed against an isolated test database (data/p4_chain_24h.db), leaving the live production chain untouched. Both runs are reported below; the 24-hour run is the confirmatory result.

Table 5.17a: P4 Stability Results — Initial Pilot Run (4.85 hours)

Table 5.17b: P4 Stability Results — Full 24-Hour Confirmation Run (23.22 h)

Chain growth in both runs reflects the stability protocol appending 10 synthetic blocks per sample (30 samples → +290 blocks, from an initial 11), not live camera traffic; the isolated test database (data/p4_chain_24h.db) was used precisely so this synthetic growth never touched the production chain.

Table 5.18: P4 RAM Trend Analysis (24-Hour Run)

Target: RAM slope < 1 MB/sample (no memory leak) — MET for both the 4.85-hour pilot and the full 24-hour confirmation run. All 60 samples across both runs valid.

[Insert Figure 5.4 — RAM and CPU trend over the 24-hour run, generated via generate_report.py]

Discussion: The full 24-hour run confirms the trend observed in the initial pilot: CPU usage remained low and stable (mean 0.58%, SD 0.25, slope +0.0145%/sample) and RAM usage showed only a small, slightly positive drift (mean 29.90 MB, total drift +0.63 MB over 23.22 hours, slope +0.0133 MB/sample) — two orders of magnitude below the 1 MB/sample leak criterion. The chain grew from 11 to 301 blocks and remained valid at every one of the 30 sampled points; per-sample chain verification time grew from 0.60 ms to 14.16 ms as chain length increased, consistent with the O(n) scaling established in P3 (§5.3.3). Taken together with the pilot run, these results provide confirmatory evidence — not merely a preliminary indication — that the framework exhibits no memory leak and no meaningful CPU drift under continuous operation over a full-day window.

5.4 Overall Discussion

5.4.1 Hash Chain Integrity Effectiveness

Across the nine tamper-detection experiments conducted to date (E1–E9), the framework achieved 100% detection for seven of nine attack classes (E1–E5, E8, E9), with the two exceptions being mechanistically well understood rather than unexplained failures. E6 (replay, 53.3%) and E7 (chain rewrite, 0% local) both fail for the same underlying reason: local self-verification can only detect inconsistency within the chain's own stored fields, and an adversary capable of recomputing hashes after tampering (in scope under the threat model, §3.1.1) can always produce a locally self-consistent — but substantively fraudulent — chain. This is not a defect specific to this implementation; it is the fundamental limitation of any hash-chain-only integrity scheme, and it is precisely why the cloud anchor (Layer 3's secondary mechanism, §3.5.6) exists: an independently timestamped, externally stored checkpoint cannot be altered by an adversary who has compromised only the edge device. E6 and E7 together constitute the strongest evidence in this thesis for why cloud anchoring is a necessary component of the framework rather than an optional enhancement — without it, both attack classes would go completely undetected.

5.4.2 Edge Device Suitability

The performance results (P1–P3) collectively indicate that the Jetson Nano is well suited to sustaining this framework: no statistically significant CPU overhead was detected (P1), hash throughput exceeds the frame-capture demand by roughly four orders of magnitude (P2), and verification time scales linearly and remains sub-second even at tens of thousands of blocks (P3). Beyond the controlled benchmark experiments, the system's live deployment provides additional longitudinal evidence of edge-device suitability: as of 2026-04-29, the production chain had accumulated over 211,860 blocks (with the AWS parking_blockchain table holding approximately 25,923 checkpoint records and parking_frames approximately 259,229 detection records), reflecting weeks of continuous unattended operation. This scale of accumulated data — arising from ordinary operation rather than a synthetic benchmark — corroborates the P1–P3 findings under real-world conditions, though it should be noted that not every block in the live chain corresponds to a genuine camera frame; a subset of early blocks originated from the initial 4.85-hour P4 pilot test, which was (in hindsight) run against the live database rather than an isolated test database — a practice corrected for the full 24-hour P4 confirmation run (§5.3.4), which used an isolated test database (data/p4_chain_24h.db) and left the production chain untouched.

5.4.3 Cloud Anchor Contribution

The cloud anchor's contribution cannot be directly quantified from the local-only detection rates reported in §5.2, since verify_against_cloud() results were not included in the E6/E7 experiment runs analysed above (this is identified as a gap for a follow-up experiment, see §6.4). Architecturally, an externally held checkpoint is the only remaining source of ground truth against attack classes that are structurally undetectable by local verification — E6 Scenarios C/D and all of E7 — because it is the only record the local adversary does not author.

That argument, however, requires the external record to actually be external to the adversary, and in the configuration evaluated here it is not. The edge device necessarily holds IAM credentials permitting PutItem on the parking_blockchain table, so the device-write capability that §3.1.1 places in scope also confers cloud-write capability. Two implementation properties then remove the anchor's remaining value against that adversary: CloudAnchor.upload_checkpoint() issues an unconditional put_item, so existing checkpoints can be overwritten rather than only appended; and anchored_at is device-generated (§3.5.6), so the recorded anchoring time can be set arbitrarily. An adversary who rewrites the local chain and then re-uploads the corresponding checkpoints produces a local chain and a cloud record that agree, and verify_against_cloud() reports no mismatch. The cloud anchor's necessity as an architectural component therefore stands, but its sufficiency as implemented does not, and no detection claim against E6 C/D or E7 can be supported by the current deployment. The hardening required to make the argument hold — and the experiments that would then be able to test it — are specified in §5.4.5.

5.4.4 N2 — Chain Structure versus Direct Anchoring

A natural challenge to the framework's design is whether the hash chain earns its place at all: if the cloud anchor is what ultimately provides external ground truth (§5.4.3), why not discard the chain and upload each frame's hash to DynamoDB as an independent record? Experiment N2 was designed to answer this as a measurement rather than an argument.

The comparison must be normalised by cost, because the intuitive answer is wrong. It is tempting to claim that independent per-frame records cannot detect deletion — but if each record carries its block_index, a deleted frame leaves a gap in the anchored index sequence, and scanning for such gaps is trivial. The distinction only appears once both schemes are constrained to the same cloud-write budget. Both were therefore allocated one write per ten frames, matching the deployed checkpoint interval (§3.5.6): 100 writes per 1,000-block chain.

• Chain scheme: every tenth block's block_hash is anchored. The nine intervening blocks are covered transitively, because each block's previous_hash binds its predecessor up to the next anchor.
• Direct scheme: no linkage. Records are independent (block_index, frame_hash) pairs, and the same budget buys coverage of only one frame in ten. The other nine have no cloud record of any kind.

Deletion and injection were then applied identically to both schemes, at a uniformly random target index, with 30 trials per attack per scheme.

Table 5.19: N2 Detection at Equal Cloud-Write Budget (100 writes per 1,000 frames)

Discussion: At equal cost the chain detects every tampering event; direct anchoring detects 6.7% of deletions and none of the injections. The mechanism behind those figures is confirmed by the per-trial records rather than merely asserted. Both deletions the direct scheme did catch had target_was_anchored = 1, and every deletion that landed on an anchored index was caught (2 of 2) — the scheme detects tampering precisely at the one-in-ten indices it records, and is blind everywhere else. With targets drawn uniformly, 2 of 30 is consistent with the expected one-in-ten rate.

Injection is detected at 0% by the direct scheme even when the target index is anchored, which is a genuine property rather than an artefact: a duplicated block_index collides within a per-index record set, and independent records carry no notion of how many blocks should lie between two anchors. The chain has that notion implicitly, because linkage must be continuous.

The correct statement of the chain's value is therefore neither "the chain detects deletion and direct anchoring does not" (false) nor "the chain is more secure" (unquantified), but rather: the chain provides deletion and reordering coverage over all frames at 1/N of the anchoring cost, where N is the checkpoint interval. Independent anchoring can match that coverage only by anchoring every frame — a tenfold increase in cloud writes, which at the live deployment's scale would mean roughly 259,000 records instead of the approximately 25,900 checkpoints actually stored (§5.4.2). The chain is, in effect, a compression mechanism that lets one cloud write vouch for N frames.

Two caveats bound the claim. The deletion and injection operations used here are simplified index-level manipulations applied identically to both schemes — deliberately, since a fair comparison requires the same tampering to reach both — and are not the attack_frame_deletion()/attack_frame_injection() routines used in E2/E3; the rates in Table 5.19 are therefore comparable within this experiment and should not be read against Tables 5.2 and 5.3. Second, this experiment measures detection coverage at equal cost, not resistance to the credential-inheriting adversary discussed in §5.4.3; that limitation applies to both schemes equally, since both depend on cloud records the device can currently overwrite.

5.4.5 Limitations

• Detection accuracy of Layer 1 (Canny-based occupancy classification) depends on lighting conditions, camera angle, and the empirically calibrated pixel-count threshold (revised from 500 to 300 during deployment, §3.3.2); a dedicated accuracy evaluation against manually labelled ground truth is a separate, scheduled activity (SONNET_TASK_PLAN.md T3.2) not covered by this chapter.
• Canny thresholds require recalibration if the camera is repositioned or lighting conditions change substantially.
• Physical spoofing (E10, pending) cannot be prevented by the hash chain layer by design — the hash chain records whatever Layer 1 reports faithfully, regardless of whether that report reflects genuine occupancy; this is a deliberate separation of concerns between detection accuracy and data integrity, not a flaw.
• The cloud anchor provides no guarantee against this thesis's own primary adversary, as currently implemented. Replay attacks with recomputed hashes (E6 Scenarios C/D) and chain rewrite attacks (E7) are undetectable through local verification alone, so mitigating them depends entirely on the cloud checkpoint record. However, because the edge device holds IAM credentials permitting PutItem, an adversary with the in-scope device-write capability (§3.1.1) inherits cloud-write capability; because upload_checkpoint() issues an unconditional put_item, that adversary can overwrite existing checkpoints; and because anchored_at is device-generated, they can also control the recorded anchoring time (§5.4.3). This is the most significant limitation identified in this work. Three changes are required to close it, and are proposed as the immediate next step rather than as open-ended future work: (i) make the checkpoint store append-only, so that a previously written checkpoint cannot be overwritten by any holder of the device's credentials — noting that a client-side DynamoDB ConditionExpression is insufficient, since an adversary holding the credentials can simply omit it, and the constraint must therefore be enforced by the storage service itself (for example Amazon S3 Object Lock with versioning, using governance mode during development and compliance mode in production) or by mediating writes through a separate service identity the device does not possess; (ii) derive the anchoring time server-side (S3 LastModified, DynamoDB Streams ApproximateCreationDateTime, or CloudTrail event time) so that it is not device-authored; and (iii) pin verification to the earliest stored version of each checkpoint, since under object versioning an adversary retaining PutObject can still write a later version, and a verifier reading only the newest one would read the forgery. E6 and E7 should then be re-run under the hardened configuration; only those results could support a claim that the anchor detects these attack classes.
• Separately from the above, detection also depends on the checkpoint interval (currently every 10 blocks) — an attacker who tampers with blocks between two checkpoints and restores consistency before the next checkpoint upload could evade even a correctly hardened anchor. Characterising this tamper window as a function of the anchoring interval is proposed as a dedicated experiment (§6.4).
• The cloud anchor requires network connectivity; prolonged offline operation would delay checkpoint uploads and correspondingly widen the window of undetected local-only tampering described above.
• Chain verification time grows linearly with chain length (P3); at the live chain's current scale (>200,000 blocks), full verification takes on the order of several seconds, which is acceptable today but would require periodic archiving or checkpoint-based partial verification for indefinitely long deployments.
• E10 (physical spoofing) results in this chapter are incomplete as of this draft (see status note in §5.2.10) and must be finalised before submission.

5.5 Summary

This chapter presented results from nine completed tamper detection experiments (E1–E9), four completed performance benchmarks (P1–P4, including P4's full 24-hour confirmation run alongside its initial 4.85-hour pilot), two control experiments (N1 negative controls, N2 anchoring baseline), and a not-yet-conducted E10. The hash chain achieved 100% detection for seven of nine tested attack classes, with the two exceptions (E6 replay with recomputed hashes, and E7 chain rewrite) both stemming from the same well-understood structural limitation of local-only verification. Cloud anchoring is the architecturally correct response to both, but as implemented it does not close them: the edge device holds the credentials that write the checkpoints and generates their timestamps, so it provides no guarantee against the very adversary the threat model places in scope (§5.4.3). Making the checkpoint store append-only under a separate service identity, with server-derived anchoring times, is accordingly the immediate next step rather than optional hardening (§5.4.5). Performance benchmarks show no statistically significant CPU overhead, hash throughput exceeding the 100 hashes/second design target by roughly two orders of magnitude, confirmed O(n) verification scaling, and no memory leak or CPU drift over a full 24-hour operational window (23.2 h between first and last samples), together supporting the suitability of the proposed framework for continuous deployment on resource-constrained edge devices. The control experiments qualify these findings in two ways: no detection mechanism produced a false positive across 30 untampered chains (N1), so the reported detection rates reflect genuine discrimination rather than an indiscriminate verifier; and at an equal cloud-write budget the chain detected 100% of deletions and injections against 6.7% and 0% respectively for independent per-frame anchoring (N2), quantifying what the chain structure contributes over direct anchoring at the same cost. Chapter 6 presents the conclusions drawn from these findings — to be finalised once the E10 field session and Layer 1 accuracy evaluation are complete — and directions for future research.

Chapter 6 — Conclusion and Future Work

Not drafted.

Not yet written.

This chapter has not been drafted. It is shown here so the table of contents reflects the true state of the thesis rather than omitting the gap.

Reference List

3,890 words · source references_thesis.md

Thesis Reference List (IEEE numeric)

118 references, every entry verified and every entry cited in the text. Entries [1]-[36] are the curated set built in T4.1 and cited in Chapter 2; each was confirmed by an actual search or registry fetch returning title, venue, year and authors, and is documented with its verification evidence in references.md.

Entries [37]-[117] were harvested from the earlier draft and independently re-verified: each was matched against the Crossref REST API by bibliographic text (title, authors, year) rather than by trusting the DOI printed in that draft. This matters -- several DOIs in the earlier draft were truncated, and one (10.1007/springerURL) was a placeholder that resolves to nothing. All metadata below is as returned by Crossref, not as transcribed from the draft.

Verification method and per-entry evidence: see references.md. Bulk verification log: matched.json (Crossref match confidence per entry).

Core set (cited in Chapter 2)

[1] F. Al-Turjman and A. Malekloo, "Smart parking in IoT-enabled cities: A survey," Sustainable Cities and Society, vol. 49, art. 101608, 2019. doi: 10.1016/j.scs.2019.101608

[2] S. S. Channamallu, S. Kermanshachi, J. M. Rosenberger, and A. Pamidimukkala, "A review of smart parking systems," Transportation Research Procedia, vol. 73, pp. 289–296, 2023. doi: 10.1016/j.trpro.2023.11.920

[3] C.-C. Huang, Y.-S. Tai, and S.-J. Wang, "Vacant parking space detection based on plane-based Bayesian hierarchical framework," IEEE Transactions on Circuits and Systems for Video Technology, vol. 23, no. 9, pp. 1598–1610, 2013. doi: 10.1109/TCSVT.2013.2254961

[4] J. Canny, "A computational approach to edge detection," IEEE Transactions on Pattern Analysis and Machine Intelligence, vol. PAMI-8, no. 6, pp. 679–698, 1986. doi: 10.1109/TPAMI.1986.4767851

[5] P. R. L. de Almeida, L. S. Oliveira, A. S. Britto Jr., E. J. Silva Jr., and A. L. Koerich, "PKLot – A robust dataset for parking lot classification," Expert Systems with Applications, vol. 42, no. 11, pp. 4937–4949, 2015. doi: 10.1016/j.eswa.2015.02.009

[6] G. Amato, F. Carrara, F. Falchi, C. Gennaro, C. Meghini, and C. Vairo, "Deep learning for decentralized parking lot occupancy detection," Expert Systems with Applications, vol. 72, pp. 327–334, 2017. doi: 10.1016/j.eswa.2016.10.055

[7] D. Acharya, W. Yan, and K. Khoshelham, "Real-time image-based parking occupancy detection using deep learning," in Proc. 5th Annu. Conf. Research@Locate, Adelaide, Australia, CEUR Workshop Proceedings, vol. 2087, pp. 33–40, 2018.

[8] A. Costin, "Security of CCTV and video surveillance systems: Threats, vulnerabilities, attacks, and mitigations," in Proc. 6th Int. Workshop on Trustworthy Embedded Devices (TrustED '16), Vienna, Austria, pp. 45–54, 2016. doi: 10.1145/2995289.2995290

[9] J. Obermaier and M. Hutle, "Analyzing the security and privacy of cloud-based video surveillance systems," in Proc. 2nd ACM Int. Workshop on IoT Privacy, Trust, and Security (IoTPTS '16), Xi'an, China, 2016. doi: 10.1145/2899007.2899008

[10] K. Sitara and B. M. Mehtre, "Digital video tampering detection: An overview of passive techniques," Digital Investigation, vol. 18, pp. 8–22, 2016. doi: 10.1016/j.diin.2016.06.003

[11] W. Wang and H. Farid, "Exposing digital forgeries in video by detecting duplication," in Proc. 9th Workshop on Multimedia & Security (MM&Sec '07), pp. 35–42, 2007. doi: 10.1145/1288869.1288876

[12] S. Haber and W. S. Stornetta, "How to time-stamp a digital document," Journal of Cryptology, vol. 3, no. 2, pp. 99–111, 1991. doi: 10.1007/BF00196791

[13] D. Bayer, S. Haber, and W. S. Stornetta, "Improving the efficiency and reliability of digital time-stamping," in Sequences II, R. Capocelli, A. De Santis, and U. Vaccaro, Eds. New York, NY: Springer, 1993, pp. 329–334. doi: 10.1007/978-1-4613-9323-8_24

[14] R. C. Merkle, "Protocols for public key cryptosystems," in Proc. 1980 IEEE Symp. on Security and Privacy, Oakland, CA, USA, pp. 122–134, 1980.

[15] R. C. Merkle, "A digital signature based on a conventional encryption function," in Advances in Cryptology — CRYPTO '87, Lecture Notes in Computer Science, vol. 293. Berlin, Heidelberg: Springer, 1987, pp. 369–378. doi: 10.1007/3-540-48184-2_32

[16] B. Schneier and J. Kelsey, "Cryptographic support for secure logs on untrusted machines," in Proc. 7th USENIX Security Symp., San Antonio, TX, USA, pp. 53–62, 1998.

[17] B. Schneier and J. Kelsey, "Secure audit logs to support computer forensics," ACM Transactions on Information and System Security, vol. 2, no. 2, pp. 159–176, May 1999. doi: 10.1145/317087.317089

[18] S. A. Crosby and D. S. Wallach, "Efficient data structures for tamper-evident logging," in Proc. 18th USENIX Security Symp., Montreal, QC, Canada, pp. 317–334, 2009.

[19] D. Ma and G. Tsudik, "A new approach to secure logging," ACM Transactions on Storage, vol. 5, no. 1, art. 2, pp. 1–21, 2009. doi: 10.1145/1502777.1502779

[20] J. E. Holt, "Logcrypt: Forward security and public verification for secure audit logs," in Proc. 2006 Australasian Workshops on Grid Computing and e-Research (ACSW Frontiers '06), pp. 203–211, 2006.

[118] D. C. Shoup, "Cruising for parking," Transport Policy, vol. 13, no. 6, pp. 479–486, 2006. doi: 10.1016/j.tranpol.2006.05.005

[21] B. Laurie, A. Langley, and E. Kasper, "Certificate Transparency," RFC 6962, Internet Engineering Task Force, June 2013. doi: 10.17487/RFC6962

[22] B. Laurie, "Certificate transparency," Communications of the ACM, vol. 57, no. 10, pp. 40–46, 2014. doi: 10.1145/2659897

[23] C. Adams, P. Cain, D. Pinkas, and R. Zuccherato, "Internet X.509 public key infrastructure time-stamp protocol (TSP)," RFC 3161, Internet Engineering Task Force, Aug. 2001. doi: 10.17487/RFC3161

[24] National Institute of Standards and Technology, Secure Hash Standard (SHS), FIPS PUB 180-4, Aug. 2015. doi: 10.6028/NIST.FIPS.180-4

[25] S. Nakamoto, "Bitcoin: A peer-to-peer electronic cash system," self-published white paper, Oct. 2008. [Online]. Available: https://bitcoin.org/bitcoin.pdf

[26] E. Androulaki et al., "Hyperledger Fabric: A distributed operating system for permissioned blockchains," in Proc. 13th EuroSys Conf. (EuroSys '18), Porto, Portugal, pp. 1–15, 2018. doi: 10.1145/3190508.3190538

[27] A. Dorri, S. S. Kanhere, and R. Jurdak, "Towards an optimized blockchain for IoT," in Proc. 2nd Int. Conf. on Internet-of-Things Design and Implementation (IoTDI '17), pp. 173–178, 2017. doi: 10.1145/3054977.3055003

[28] A. Dorri, S. S. Kanhere, R. Jurdak, and P. Gauravaram, "LSB: A lightweight scalable blockchain for IoT security and anonymity," Journal of Parallel and Distributed Computing, vol. 134, pp. 180–197, 2019. doi: 10.1016/j.jpdc.2019.08.005

[29] A. Reyna, C. Martín, J. Chen, E. Soler, and M. Díaz, "On blockchain and its integration with IoT: Challenges and opportunities," Future Generation Computer Systems, vol. 88, pp. 173–190, 2018. doi: 10.1016/j.future.2018.05.046

[30] X. Liang, S. Shetty, D. Tosh, C. Kamhoua, K. Kwiat, and L. Njilla, "ProvChain: A blockchain-based data provenance architecture in cloud environment with enhanced privacy and availability," in Proc. 17th IEEE/ACM Int. Symp. on Cluster, Cloud and Grid Computing (CCGrid '17), pp. 468–477, 2017. doi: 10.1109/CCGRID.2017.8

[31] D. V. Medhane, A. K. Sangaiah, M. S. Hossain, G. Muhammad, and J. Wang, "Blockchain-enabled distributed security framework for next-generation IoT: An edge cloud and software-defined network-integrated approach," IEEE Internet of Things Journal, vol. 7, no. 7, pp. 6143–6149, Jul. 2020. doi: 10.1109/JIOT.2020.2977196

[32] M. S. Rahman, M. A. P. Chamikara, I. Khalil, and A. Bouras, "Blockchain-of-blockchains: An interoperable blockchain platform for ensuring IoT data integrity in smart city," Journal of Industrial Information Integration, vol. 30, art. 100408, 2022. doi: 10.1016/j.jii.2022.100408

[33] W. Shi, J. Cao, Q. Zhang, Y. Li, and L. Xu, "Edge computing: Vision and challenges," IEEE Internet of Things Journal, vol. 3, no. 5, pp. 637–646, 2016. doi: 10.1109/JIOT.2016.2579198

[34] M. Satyanarayanan, "The emergence of edge computing," Computer, vol. 50, no. 1, pp. 30–39, 2017. doi: 10.1109/MC.2017.9

[35] R. Roman, J. Lopez, and M. Mambo, "Mobile edge computing, Fog et al.: A survey and analysis of security threats and challenges," Future Generation Computer Systems, vol. 78, pp. 680–698, 2018. doi: 10.1016/j.future.2016.11.009

[36] A. A. Süzen, B. Duman, and B. Şen, "Benchmark analysis of Jetson TX2, Jetson Nano and Raspberry PI using Deep-CNN," in Proc. 2020 Int. Congr. on Human-Computer Interaction, Optimization and Robotic Applications (HORA), 2020. doi: 10.1109/HORA49412.2020.9152915

Extended set (verified; from the earlier draft's bibliography)

Smart parking and vehicle detection (12)

[37] B. Padmavathi, and V. Selvaraj, "Advanced optimization-based weighted features for ensemble deep learning smart occupancy detection network for road traffic parking," Journal of Network and Computer Applications, vol. 230, pp. 103924, 2024. doi: 10.1016/j.jnca.2024.103924

[38] W. A. Jabbar, L. Y. Tiew, and N. Y. Ali Shah, "Internet of things enabled parking management system using long range wide area network for smart city," Internet of Things and Cyber-Physical Systems, vol. 4, pp. 82-98, 2024. doi: 10.1016/j.iotcps.2023.09.001

[39] A. Aditya, S. Anwarul, R. Tanwar, and S. K. V. Koneru, "An IoT assisted Intelligent Parking System (IPS) for Smart Cities," Procedia Computer Science, vol. 218, pp. 1045-1054, 2023. doi: 10.1016/j.procs.2023.01.084

[40] J. R. Santana, P. Sotres, J. Pérez, L. Sánchez, J. Lanza, and L. Muñoz, "Assessing LoRaWAN radio propagation for smart parking service: An experimental study," Computer Networks, vol. 235, pp. 109962, 2023. doi: 10.1016/j.comnet.2023.109962

[41] M. Venkata Sudhakar, A. Anoora Reddy, K. Mounika, M. Sai Kumar, and T. Bharani, "Development of smart parking management system," Materials Today: Proceedings, vol. 80, pp. 2794-2798, 2023. doi: 10.1016/j.matpr.2021.07.040

[42] V. Rajyalakshmi, and K. Lakshmanna, "Intelligent Face Recognition Based Multi-Location Linked IoT Based Car Parking System," IEEE Access, vol. 11, pp. 84258-84269, 2023. doi: 10.1109/access.2023.3302905

[43] A. Floris, S. Porcu, L. Atzori, and R. Girau, "A Social IoT-based platform for the deployment of a smart parking solution," Computer Networks, vol. 205, pp. 108756, 2022. doi: 10.1016/j.comnet.2021.108756

[44] M. Veeramanickam, B. Venkatesh, L. A. Bewoor, Y. W. Bhowte, K. Moholkar, and J. L. Bangare, "IoT based smart parking model using Arduino UNO with FCFS priority scheduling," Measurement: Sensors, vol. 24, pp. 100524, 2022. doi: 10.1016/j.measen.2022.100524

[45] T. Limbasiya, S. K. Sahay, and D. Das, "SAMPARK: Secure and lightweight communication protocols for smart parking management," Journal of Information Security and Applications, vol. 71, pp. 103381, 2022. doi: 10.1016/j.jisa.2022.103381

[46] H. Canli, and S. Toklu, "Deep Learning-Based Mobile Application Design for Smart Parking," IEEE Access, vol. 9, pp. 61171-61183, 2021. doi: 10.1109/access.2021.3074887

[47] D. Nugraha, F. Y. H. Ahmed, M. I. Abdullah, and M. G. M. Johar, "Survey of smart parking application deployment," IOP Conference Series: Materials Science and Engineering, vol. 1108, no. 1, pp. 012019, 2021. doi: 10.1088/1757-899x/1108/1/012019

[48] S. Alkhuraiji, "Design and Implementation of an Android Smart Parking Mobile Application," TEM Journal, pp. 1357-1363, 2020. doi: 10.18421/tem94-06

Blockchain, ledgers and IoT security (22)

[49] J. Zhu, F. Li, and J. Chen, "A survey of blockchain, artificial intelligence, and edge computing for Web 3.0," Computer Science Review, vol. 54, pp. 100667, 2024. doi: 10.1016/j.cosrev.2024.100667

[50] D. L. Moura, A. L. Aquino, and A. A. Loureiro, "An edge computing and distributed ledger technology architecture for secure and efficient transportation," Ad Hoc Networks, vol. 164, pp. 103633, 2024. doi: 10.1016/j.adhoc.2024.103633

[51] Y. Yin, X. Wang, H. Wang, and B. Lu, "Application of edge computing and IoT technology in supply chain finance," Alexandria Engineering Journal, vol. 108, pp. 754-763, 2024. doi: 10.1016/j.aej.2024.09.016

[52] A. Rizzardi, S. Sicari, J. F. Cevallos M., and A. Coen-Porisini, "IoT-driven blockchain to manage the healthcare supply chain and protect medical records," Future Generation Computer Systems, vol. 161, pp. 415-431, 2024. doi: 10.1016/j.future.2024.07.039

[53] Israa Al_Barazanchi et al., "Blockchain Technology - Based Solutions for IOT Security," Iraqi Journal for Computer Science and Mathematics, pp. 53-63, 2022. doi: 10.52866/ijcsm.2022.01.01.006

[54] D. Liao, H. Li, W. Wang, X. Wang, M. Zhang, and X. Chen, "Achieving IoT data security based blockchain," Peer-to-Peer Networking and Applications, vol. 14, no. 5, pp. 2694-2707, 2021. doi: 10.1007/s12083-020-01042-w

[55] B. K. Mohanta, D. Jena, S. Ramasubbareddy, M. Daneshmand, and A. H. Gandomi, "Addressing Security and Privacy Issues of IoT Using Blockchain Technology," IEEE Internet of Things Journal, vol. 8, no. 2, pp. 881-888, 2021. doi: 10.1109/jiot.2020.3008906

[56] S. Saxena, B. Bhushan, and M. A. Ahad, "Blockchain based solutions to secure IoT: Background, integration trends and a way forward," Journal of Network and Computer Applications, vol. 181, pp. 103050, 2021. doi: 10.1016/j.jnca.2021.103050

[57] C. Schinckus, "Proof-of-work based blockchain technology and Anthropocene: An undermined situation?," Renewable and Sustainable Energy Reviews, vol. 152, pp. 111682, 2021. doi: 10.1016/j.rser.2021.111682

[58] K. O. Toka, Y. Dikilitaş, T. Oktay, and A. Sayar, "SECURING IOT WITH BLOCKCHAIN," The International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, vol. XLVI-4/W5-2021, pp. 529-532, 2021. doi: 10.5194/isprs-archives-xlvi-4-w5-2021-529-2021

[59] R. Garg, P. Gupta, and A. Kaur, "Secure IoT via Blockchain," IOP Conference Series: Materials Science and Engineering, vol. 1022, no. 1, pp. 012048, 2021. doi: 10.1088/1757-899x/1022/1/012048

[60] V. Upadrista, "Security in IoT," IoT Standards with Blockchain, pp. 143-160, 2021. doi: 10.1007/978-1-4842-7271-8_8

[61] A. Rahman et al., "SmartBlock-SDN: An Optimized Blockchain-SDN Framework for Resource Management in IoT," IEEE Access, vol. 9, pp. 28361-28376, 2021. doi: 10.1109/access.2021.3058244

[62] O. Alfandi, S. Khanji, L. Ahmad, and A. Khattak, "A survey on boosting IoT security and privacy through blockchain," Cluster Computing, vol. 24, no. 1, pp. 37-55, 2020. doi: 10.1007/s10586-020-03137-8

[63] Q. Wang, X. Zhu, Y. Ni, L. Gu, and H. Zhu, "Blockchain for the IoT and industrial IoT: A review," Internet of Things, vol. 10, pp. 100081, 2020. doi: 10.1016/j.iot.2019.100081

[64] K. P. Dirgantoro, J. M. Lee, and D. S. Kim, "Generative Adversarial Networks Based on Edge Computing With Blockchain Architecture for Security System," 2020 International Conference on Artificial Intelligence in Information and Communication (ICAIIC), pp. 039-042, 2020. doi: 10.1109/icaiic48513.2020.9065231

[65] M. H. Miraz, and M. Ali, "Integration of Blockchain and IoT: An Enhanced Security Perspective," Annals of Emerging Technologies in Computing, vol. 4, no. 4, pp. 52-63, 2020. doi: 10.33166/aetic.2020.04.006

[66] M. Du et al., "Spacechain: A Three-Dimensional Blockchain Architecture for IoT Security," IEEE Wireless Communications, vol. 27, no. 3, pp. 38-45, 2020. doi: 10.1109/mwc.001.1900466

[67] A. Dhiran, D. Kumar, Abhishek, and A. Arora, "Video Fraud Detection using Blockchain," 2020 Second International Conference on Inventive Research in Computing Applications (ICIRCA), pp. 102-107, 2020. doi: 10.1109/icirca48905.2020.9182963

[68] Y. Jeong, D. Hwang, and K. H. Kim, "Blockchain-Based Management of Video Surveillance Systems," 2019 International Conference on Information Networking (ICOIN), pp. 465-468, 2019. doi: 10.1109/icoin.2019.8718126

[69] Y. Liu, F. R. Yu, X. Li, H. Ji, and V. C. M. Leung, "Decentralized Resource Allocation for Video Transcoding and Delivery in Blockchain-Based System With Mobile Edge Computing," IEEE Transactions on Vehicular Technology, vol. 68, no. 11, pp. 11169-11185, 2019. doi: 10.1109/tvt.2019.2937351

[70] M. Liu, F. R. Yu, Y. Teng, V. C. M. Leung, and M. Song, "Distributed Resource Allocation in Blockchain-Based Video Streaming Systems With Mobile Edge Computing," IEEE Transactions on Wireless Communications, vol. 18, no. 1, pp. 695-708, 2019. doi: 10.1109/twc.2018.2885266

Computer vision and video processing (20)

[71] H. Wang et al., "A systematic literature review of computer vision applications in robotized wire harness assembly," Advanced Engineering Informatics, vol. 62, pp. 102596, 2024. doi: 10.1016/j.aei.2024.102596

[72] B. Xiao, Y. Wang, Y. Zhang, C. Chen, and A. Darko, "Automated daily report generation from construction videos using ChatGPT and computer vision," Automation in Construction, vol. 168, pp. 105874, 2024. doi: 10.1016/j.autcon.2024.105874

[73] X. Yang, Y. Li, and Q. Chen, "Automated image-based fire detection and alarm system using edge computing and cloud-based platform," Internet of Things, vol. 28, pp. 101402, 2024. doi: 10.1016/j.iot.2024.101402

[74] H. Gebrye, Y. Wang, and F. Li, "Computer vision based distributed denial of service attack detection for resource-limited devices," Computers and Electrical Engineering, vol. 120, pp. 109716, 2024. doi: 10.1016/j.compeleceng.2024.109716

[75] S. Ghazal, A. Munir, and W. S. Qureshi, "Computer vision in smart agriculture and precision farming: Techniques and applications," Artificial Intelligence in Agriculture, vol. 13, pp. 64-83, 2024. doi: 10.1016/j.aiia.2024.06.004

[76] B. Ekanayake, J. K. W. Wong, A. A. F. Fini, P. Smith, and V. Thengane, "Deep learning-based computer vision in project management: Automating indoor construction progress monitoring," Project Leadership and Society, vol. 5, pp. 100149, 2024. doi: 10.1016/j.plas.2024.100149

[77] M. Ergen et al., "Edge computing in future wireless networks: A comprehensive evaluation and vision for 6G and beyond," ICT Express, vol. 10, no. 5, pp. 1151-1173, 2024. doi: 10.1016/j.icte.2024.08.007

[78] M. Katsigiannis, and K. Mykoniatis, "Enhancing industrial IoT with edge computing and computer vision: An analog gauge visual digitization approach," Manufacturing Letters, vol. 41, pp. 1264-1273, 2024. doi: 10.1016/j.mfglet.2024.09.153

[79] M. Guzman, B. Q. Geuther, G. S. Sabnis, and V. Kumar, "Highly accurate and precise determination of mouse mass using computer vision," Patterns, vol. 5, no. 9, pp. 101039, 2024. doi: 10.1016/j.patter.2024.101039

[80] H. Gauttam, K. Pattanaik, S. Bhadauria, and G. Nain, "SCL: A sustainable deep learning solution for edge computing ecosystem in smart manufacturing," Journal of Industrial Information Integration, vol. 42, pp. 100703, 2024. doi: 10.1016/j.jii.2024.100703

[81] I. Yousif, J. Samaha, J. Ryu, and R. Harik, "Safety 4.0: Harnessing computer vision for advanced industrial protection," Manufacturing Letters, vol. 41, pp. 1342-1356, 2024. doi: 10.1016/j.mfglet.2024.09.161

[82] Z. Peng, J. Li, H. Hao, and Y. Zhong, "Smart structural health monitoring using computer vision and edge computing," Engineering Structures, vol. 319, pp. 118809, 2024. doi: 10.1016/j.engstruct.2024.118809

[83] R. Hajlaoui, T. Moulahi, S. Zidi, S. El Khediri, B. Alaya, and S. Zeadally, "Towards smarter cyberthreats detection model for industrial internet of things (IIoT) 4.0," Journal of Industrial Information Integration, vol. 39, pp. 100595, 2024. doi: 10.1016/j.jii.2024.100595

[84] B. L. Lawrence, and E. de Lemmus, "Using computer vision to classify, locate and segment fire behavior in UAS-captured images," Science of Remote Sensing, vol. 10, pp. 100167, 2024. doi: 10.1016/j.srs.2024.100167

[85] A. L. S. de Moraes, D. D. de Macedo, and L. Pioli, "Video streaming on fog and edge computing layers: A systematic mapping study," Internet of Things, vol. 28, pp. 101359, 2024. doi: 10.1016/j.iot.2024.101359

[86] D. Dhabliya, I. S. M. Ugli, M. J. Murali, A. H. R. Abbas, and U. Gulbahor, "Computer Vision: Advances in Image and Video Analysis," E3S Web of Conferences, vol. 399, pp. 04045, 2023. doi: 10.1051/e3sconf/202339904045

[87] Y. Liang, "Computer vision-based image data processing of digital media video images with ultra-clear picture quality," Applied Mathematics and Nonlinear Sciences, vol. 9, no. 1, 2023. doi: 10.2478/amns.2023.2.00557

[88] A. M. Pasikhan, J. A. Clark, and P. Gope, "Incremental hybrid intrusion detection for 6LoWPAN," Computers & Security, vol. 135, pp. 103447, 2023. doi: 10.1016/j.cose.2023.103447

[89] V. Sharma, M. Gupta, A. Kumar, and D. Mishra, "Video Processing Using Deep Learning Techniques: A Systematic Literature Review," IEEE Access, vol. 9, pp. 139489-139507, 2021. doi: 10.1109/access.2021.3118541

[90] H. Sun, Y. Yu, K. Sha, and B. Lou, "mVideo: Edge Computing Based Mobile Video Processing Systems," IEEE Access, vol. 8, pp. 11615-11623, 2020. doi: 10.1109/access.2019.2963159

Edge, fog and cloud computing (15)

[91] W. Liu, M. Bilal, Y. Shi, and X. Xu, "Distributed service caching with deep reinforcement learning for sustainable edge computing in large-scale AI," Digital Communications and Networks, vol. 11, no. 5, pp. 1447-1456, 2025. doi: 10.1016/j.dcan.2024.11.009

[92] L. Kenioua, B. Lejdel, S. Alamri, and Q. Ramadan, "A password-based authentication approach for edge computing architectures," Egyptian Informatics Journal, vol. 28, pp. 100543, 2024. doi: 10.1016/j.eij.2024.100543

[93] T. Baidya, and S. Moh, "Comprehensive survey on resource allocation for edge-computing-enabled metaverse," Computer Science Review, vol. 54, pp. 100680, 2024. doi: 10.1016/j.cosrev.2024.100680

[94] M. Palena, T. Cerquitelli, and C. F. Chiasserini, "Edge-device collaborative computing for multi-view classification," Computer Networks, vol. 254, pp. 110823, 2024. doi: 10.1016/j.comnet.2024.110823

[95] S. Elnagar, K. M. O. Bryson, and M. Thomas, "SAFERIDES: Application of decentralized control edge-computing to ridesharing monitoring services," International Journal of Information Management Data Insights, vol. 4, no. 2, pp. 100282, 2024. doi: 10.1016/j.jjimei.2024.100282

[96] S. Dong et al., "Task offloading strategies for mobile edge computing: A survey," Computer Networks, vol. 254, pp. 110791, 2024. doi: 10.1016/j.comnet.2024.110791

[97] A. M. Rahmani, S. Alsubai, A. Alanazi, A. Alqahtani, M. M. Zaidi, and M. Hosseinzadeh, "The role of mobile edge computing in advancing federated learning algorithms and techniques: A systematic review of applications, challenges, and future directions," Computers and Electrical Engineering, vol. 120, pp. 109812, 2024. doi: 10.1016/j.compeleceng.2024.109812

[98] S. M. Salman, A. V. Papadopoulos, S. Mubeen, and T. Nolte, "Dispatching Deadline Constrained Jobs in Edge Computing Systems," 2023 IEEE 28th International Conference on Emerging Technologies and Factory Automation (ETFA), pp. 1-8, 2023. doi: 10.1109/etfa54631.2023.10275562

[99] J. M. G. Sánchez et al., "Edge Computing for Cyber-physical Systems: A Systematic Mapping Study Emphasizing Trustworthiness," ACM Transactions on Cyber-Physical Systems, vol. 6, no. 3, pp. 1-28, 2022. doi: 10.1145/3539662

[100] C. Xu et al., "The Case for FPGA-Based Edge Computing," IEEE Transactions on Mobile Computing, vol. 21, no. 7, pp. 2610-2619, 2022. doi: 10.1109/tmc.2020.3041781

[101] R. T. Tiburski, C. R. Moratelli, S. F. Johann, E. de Matos, and F. Hessel, "A lightweight virtualization model to enable edge computing in deeply embedded systems," Software: Practice and Experience, vol. 51, no. 9, pp. 1964-1981, 2021. doi: 10.1002/spe.2968

[102] R. K. Das, N. Ahmed, F. H. Pohrmen, A. K. Maji, and G. Saha, "6LE-SDN: An Edge-Based Software-Defined Network for Internet of Things," IEEE Internet of Things Journal, vol. 7, no. 8, pp. 7725-7733, 2020. doi: 10.1109/jiot.2020.2990936

[103] M. H. Ghasemi, O. Lucia, and S. Lucia, "Computing in the Blink of an Eye: Current Possibilities for Edge Computing and Hardware-Agnostic Programming," IEEE Access, vol. 8, pp. 41626-41636, 2020. doi: 10.1109/access.2020.2977087

[104] H. Wu et al., "Dynamic Edge Access System in IoT Environment," IEEE Internet of Things Journal, vol. 7, no. 4, pp. 2509-2520, 2020. doi: 10.1109/jiot.2019.2943696

[105] T. KONO, Y. TAITO, and H. HIDAKA, "Essential Roles, Challenges and Development of Embedded MCU Micro-Systems to Innovate Edge Computing for the IoT/AI Age," IEICE Transactions on Electronics, vol. E103.C, no. 4, pp. 132-143, 2020. doi: 10.1587/transele.2019cdi0001

IoT networking and 6LoWPAN (12)

[106] F. F. Ashrif, E. A. Sundararajan, M. K. Hasan, R. Ahmad, S. Abdullah, and R. Wazirali, "Secured lightweight authentication for 6LoWPANs in machine-to-machine communications," Computers & Security, vol. 145, pp. 104002, 2024. doi: 10.1016/j.cose.2024.104002

[107] F. F. Ashrif, E. A. Sundararajan, R. Ahmad, M. K. Hasan, and E. Yadegaridehkordi, "Survey on the authentication and key agreement of 6LoWPAN: Open issues and future direction," Journal of Network and Computer Applications, vol. 221, pp. 103759, 2024. doi: 10.1016/j.jnca.2023.103759

[108] T. A. Al-Amiedy et al., "A systematic literature review on attacks defense mechanisms in RPL-based 6LoWPAN of Internet of Things," Internet of Things, vol. 22, pp. 100741, 2023. doi: 10.1016/j.iot.2023.100741

[109] D. Jenzeri, and A. Chehri, "Data Analysis for IoT System Using 6LoWPAN and Constrained Application Protocol for Environmental Monitoring," Procedia Computer Science, vol. 207, pp. 1472-1481, 2022. doi: 10.1016/j.procs.2022.09.204

[110] M. Tanveer, G. Abbas, Z. H. Abbas, M. Bilal, A. Mukherjee, and K. S. Kwak, "LAKE-6SH: Lightweight User Authenticated Key Exchange for 6LoWPAN-Based Smart Homes," IEEE Internet of Things Journal, vol. 9, no. 4, pp. 2578-2591, 2022. doi: 10.1109/jiot.2021.3085595

[111] A. M. Haka, V. P. Aleksieva, and H. G. Valchanov, "6LoWPAN network analysis using simulations and experiments," IOP Conference Series: Materials Science and Engineering, vol. 1032, no. 1, pp. 012015, 2021. doi: 10.1088/1757-899x/1032/1/012015

[112] W. S. Park, and C. S. Park, "Securing 6LoWPAN Neighbor Discovery," IEEE Internet of Things Journal, vol. 8, no. 17, pp. 13677-13689, 2021. doi: 10.1109/jiot.2021.3067591

[113] S. M. J. Hasan, M. Ali, T. I. Khan, F. Afrin, and M. M. Islam, "6LoWPAN Based Futuristic Smart Architecture for Home Automation," 2020 2nd International Conference on Advanced Information and Communication Technology (ICAICT), pp. 449-454, 2020. doi: 10.1109/icaict51780.2020.9333483

[114] D. Chen, J. Y. Khan, J. Brown, M. Awais Javed, and Y. Zhuang, "A 6LoWPAN OPNET simulation model for machine‐to‐machine communications," Transactions on Emerging Telecommunications Technologies, vol. 31, no. 11, 2020. doi: 10.1002/ett.4120

[115] Y. Li, and X. Wang, "Green content communications in 6LoWPAN," IET Networks, vol. 9, no. 1, pp. 38-42, 2020. doi: 10.1049/iet-net.2018.5231

[116] N. b. H. Kasah, A. H. b. M. Aman, Z. S. M. Attarbashi, and Y. Fazea, "Investigation on 6LoWPAN Data Security for Internet of Things," 2020 2nd International Conference on Computer and Information Sciences (ICCIS), pp. 1-5, 2020. doi: 10.1109/iccis49240.2020.9257661

[117] S. Kharche, and S. Pawar, "Optimizing network lifetime and QoS in 6LoWPANs using deep neural networks," Computers & Electrical Engineering, vol. 87, pp. 106775, 2020. doi: 10.1016/j.compeleceng.2020.106775

Reference Verification Record

3,907 words · source references.md

references.md — verified reference list for Chapter 2

Task: T4.1 (SONNET_TASK_PLAN.md Phase 4). Built 2026-07-30.

The rule this file enforces

Every entry below was confirmed by an actual search or publisher/registry fetch that returned title + venue + year + authors, and is recorded with a DOI or a stable URL. Nothing here is from memory or inference. Where a field could not be confirmed first-hand it is marked, not guessed.

This project was burned once by a fabricated-citation draft, so the standard is: an entry that cannot be verified does not get cited. Unverified and rejected candidates are listed in §7 rather than quietly dropped or substituted.

Citation style is deliberately not applied yet. Entries are stored as structured fields so they can be rendered into IEEE numeric or APA later — SONNET_TASK_PLAN.md Phase 6 still has "confirm citation style with user" open. Do not renumber these as though they were final in-text citation numbers.

Verification legend

Crossref-confirmed means the DOI was resolved against api.crossref.org and the returned metadata matched. That is the strongest check used here.

1. Layer 1 — vision-based parking occupancy detection

Purpose in Ch2: establish the accuracy baseline this thesis is measured against, and place the Canny approach in its actual (dated, cheap) position rather than implying novelty.

[V1] ✅ Canny, J. "A Computational Approach to Edge Detection." IEEE Transactions on Pattern Analysis and Machine Intelligence, vol. PAMI-8, no. 6, pp. 679–698, 1986. DOI: 10.1109/TPAMI.1986.4767851 → Ch2 role: the actual operator in detect_status(). Also the reference point for the ROI mask-boundary defect: Canny's non-maximum suppression and hysteresis operate on a gradient field, so pre-masking injects a synthetic step edge at every polygon border. The defect is a misuse of this operator, and should be framed that way.

[V2] ✅ de Almeida, P. R. L., Oliveira, L. S., Britto Jr., A. S., Silva Jr., E. J., Koerich, A. L. "PKLot – A robust dataset for parking lot classification." Expert Systems with Applications, vol. 42, no. 11, pp. 4937–4949, 2015. DOI: 10.1016/j.eswa.2015.02.009 — Crossref-confirmed → Ch2 role: the standard benchmark (695,899 images, weather-stratified). This is the comparison that makes our n=100 frames / 1,400 slot-readings look small — say so explicitly rather than letting an examiner raise it.

[V3] ✅ Amato, G., Carrara, F., Falchi, F., Gennaro, C., Meghini, C., Vairo, C. "Deep learning for decentralized parking lot occupancy detection." Expert Systems with Applications, vol. 72, pp. 327–334, 2017. DOI: 10.1016/j.eswa.2016.10.055 → Ch2 role: the closest sibling in framing — CNN occupancy detection on smart cameras, i.e. the same edge-decentralisation argument, with CNRPark-EXT (~150k labelled patches, 164 spaces). Their accuracy is the number our Canny detector will be compared to. Also the honest counterpoint: they moved to CNNs on-device, so "edge constraints force classical CV" is not a defensible claim in 2026.

[V4] ✅ Huang, C.-C., Tai, Y.-S., Wang, S.-J. "Vacant Parking Space Detection Based on Plane-Based Bayesian Hierarchical Framework." IEEE Transactions on Circuits and Systems for Video Technology, vol. 23, no. 9, pp. 1598–1610, 2013. DOI: 10.1109/TCSVT.2013.2254961 — Crossref-confirmed → Ch2 role: day/night, shadow, inter-object occlusion and perspective distortion as named failure modes. Our single fixed threshold (300 px) addresses none of these; this is the reference for why that is a limitation, not a design choice.

[V5] 🔖 Acharya, D., Yan, W., Khoshelham, K. "Real-time image-based parking occupancy detection using deep learning." Proc. 5th Annual Conference of Research@Locate, Adelaide, Australia, CEUR Workshop Proceedings, vol. 2087, pp. 33–40, 2018. URL: https://ceur-ws.org/Vol-2087/paper5.pdf → Ch2 role: CNN + SVM evaluated on PKLot; the "real-time on modest hardware" claim to compare our latency figures against. (CEUR proceedings carry no DOI.)

[V6] ✅ Al-Turjman, F., Malekloo, A. "Smart parking in IoT-enabled cities: A survey." Sustainable Cities and Society, vol. 49, art. 101608, 2019. DOI: 10.1016/j.scs.2019.101608 → Ch2 role: survey-level framing for §2.1; source for the observation that the smart-parking literature treats data integrity as out of scope.

[V7] ✅ Channamallu, S. S., Kermanshachi, S., Rosenberger, J. M., Pamidimukkala, A. "A review of smart parking systems." Transportation Research Procedia, vol. 73, pp. 289–296, 2023. DOI: 10.1016/j.trpro.2023.11.920 → Ch2 role: recent review, keeps §2.1 current. Harvested from the abandoned draft (its ref [12]) and independently re-verified — see §6.

2. Attack surface — video and sensor integrity

Purpose in Ch2: build the taxonomy that E1–E10 instantiate, so the experiment set looks derived from the literature rather than invented.

[A1] ✅ Costin, A. "Security of CCTV and Video Surveillance Systems: Threats, Vulnerabilities, Attacks, and Mitigations." Proc. 6th International Workshop on Trustworthy Embedded Devices (TrustED '16), Vienna, pp. 45–54, 2016. DOI: 10.1145/2995289.2995290 → Ch2 role: the systematic CCTV/IP-camera threat review. Maps directly onto our threat model and — pointedly — onto rule 8a: our own deployment's weak default RTSP credential is precisely the documented weakness class. Cite it where the camera-substitution assumption (E8) is justified. (The credential itself is deliberately not reproduced here — see CLAUDE.md rule 8a. This file is published to a public URL.)

[A2] ✅ Obermaier, J., Hutle, M. "Analyzing the Security and Privacy of Cloud-based Video Surveillance Systems." Proc. 2nd ACM International Workshop on IoT Privacy, Trust, and Security (IoTPTS '16 @ AsiaCCS), Xi'an, 2016. DOI: 10.1145/2899007.2899008 → Ch2 role: the strongest single justification for E8/E3. They demonstrate injecting forged video streams into cloud surveillance systems against real products — so feed substitution is an observed attack, not a hypothetical.

[A3] ✅ Sitara, K., Mehtre, B. M. "Digital video tampering detection: An overview of passive techniques." Digital Investigation, vol. 18, pp. 8–22, 2016. DOI: 10.1016/j.diin.2016.06.003 → Ch2 role: the active-vs-passive split is the cleanest way to position this thesis. We are firmly active (hash chain committed at capture); passive forensics infers tampering from content statistics after the fact. State which problem we solve.

[A4] ✅ Wang, W., Farid, H. "Exposing digital forgeries in video by detecting duplication." Proc. 9th Workshop on Multimedia & Security (MM&Sec '07), pp. 35–42, 2007. DOI: 10.1145/1288869.1288876 → Ch2 role: frame duplication as a named forensic problem — the literature counterpart to E6 (replay) and E8. Useful contrast: they detect duplication by content correlation; our E8 scan detects it by repeated frame_hash, which is why E8 is scoped to byte-identical replay and a re-encode evades it.

3. Integrity mechanisms — hash chains, secure logging, timestamping

This is the section that decides the viva. The "this is Haber & Stornetta 1991, what's new?" attack lands here, and the honest answer is that the mechanism is not new — the contribution has to be the empirical characterisation on constrained hardware plus the anchor-interval analysis. Every entry below is chosen to make that argument survivable.

[H1] ✅ Haber, S., Stornetta, W. S. "How to time-stamp a digital document." Journal of Cryptology, vol. 3, no. 2, pp. 99–111, 1991. DOI: 10.1007/BF00196791 → Ch2 role: the prior art. Two things must be conceded explicitly: (1) hash-linking records into a tamper-evident sequence is theirs, not ours; (2) their stated goal is that back-dating and forward-dating are infeasible "even with the collusion of a time-stamping service" (abstract, verified) — i.e. removing trust in the timestamping service is the 1991 contribution. Only their naive scheme needs a trusted TSS; the linking and distributed-random-witness schemes exist to eliminate it. That is the correct framing for known defect #1, and it is harsher than "we didn't use a trusted TSS": our anchored_at is generated by the device being audited (cloud_anchor.py, datetime.utcnow()), so there is no second party to the timestamp at all. We are below even the naive 1991 scheme, which at least had a distinct service issuing the time. State it that way — an examiner who knows this paper will otherwise state it for us. ⚠️ Argued from the verified abstract, not the full text — paywalled at Springer (link.springer.com/content/pdf/10.1007/bf00196791.pdf 303-redirects to idp.springer.com). Before Ch2 is final, read the full text via USM library access and confirm the linking-vs-random-witness trust distinction is stated as summarised. (Also appeared in CRYPTO '90, LNCS 537, pp. 437–455 — cite the journal version.)

[H2] ✅ Bayer, D., Haber, S., Stornetta, W. S. "Improving the Efficiency and Reliability of Digital Time-Stamping." In Sequences II, Capocelli, De Santis, Vaccaro (eds.), Springer, pp. 329–334, 1993. DOI: 10.1007/978-1-4613-9323-8_24 → Ch2 role: trees for efficiency, and periodic publication to a wide audience so no single service need be trusted. That is cloud anchoring, in 1993. Our anchoring interval (checkpoint every 10 blocks) is a parameter choice inside their design space — which is exactly why the anchor-interval sweep (N ∈ 1…500) is the defensible contribution rather than the anchoring idea itself.

[H3] 🔖 Merkle, R. C. "Protocols for Public Key Cryptosystems." Proc. 1980 IEEE Symposium on Security and Privacy, Oakland, CA, pp. 122–134, 1980. URL: https://www.semanticscholar.org/paper/9bb0aa7c062a1ac3df0a73d1e7caa88937e9716e → Ch2 role: origin of the hash tree. Justifies the chain-vs-tree decision: we chose a chain, and P3 measured the price — O(n) verification, 0.0399 ms/block, ≈8 s to verify the live 211k-block chain. A Merkle tree would give O(log n) membership proofs. Present this as a measured trade-off, not an oversight. ◑ No DOI located for the 1980 S&P proceedings; page range given as "122" in some secondary sources and "122–134" in others. Confirm against a copy of the proceedings before final submission.

[H4] ✅ Merkle, R. C. "A Digital Signature Based on a Conventional Encryption Function." Advances in Cryptology — CRYPTO '87, LNCS vol. 293, Springer, pp. 369–378, 1987. DOI: 10.1007/3-540-48184-2_32 → Ch2 role: the canonical hash-tree construction citation; pairs with [H3].

[H5] 🔖 Schneier, B., Kelsey, J. "Cryptographic Support for Secure Logs on Untrusted Machines." Proc. 7th USENIX Security Symposium, San Antonio, TX, pp. 53–62, 1998. URL: https://www.usenix.org/legacy/publications/library/proceedings/sec98/full_papers/schneier/schneier.pdf (ACM DL id 10.5555/1267549.1267553) → Ch2 role: the threat model we actually inherit — "the logging machine will be compromised". Their answer is forward security via key evolution: entries written before compromise stay unforgeable afterwards.

[H6] ✅ Schneier, B., Kelsey, J. "Secure audit logs to support computer forensics." ACM Transactions on Information and System Security, vol. 2, no. 2, pp. 159–176, May 1999. DOI: 10.1145/317087.317089 → Ch2 role: the journal version of [H5], and the sharpest statement of known defect #2. We have no forward security: the device holds live IAM PutItem credentials and upload_checkpoint() issues an unconditional put_item, so a device-level attacker — our own primary adversary — can rewrite history and its anchor. Schneier & Kelsey solved the 1999 version of this. Ch2 should set up that comparison so Ch5 §5.4.5 can pay it off.

[H7] 🔖 Crosby, S. A., Wallach, D. S. "Efficient Data Structures for Tamper-Evident Logging." Proc. 18th USENIX Security Symposium, Montreal, pp. 317–334, 2009. URL: https://www.usenix.org/conference/usenixsecurity09/technical-sessions/presentation/efficient-data-structures-tamper-evident (ACM DL id 10.5555/1855768.1855788; pages confirmed via dblp) → Ch2 role: the untrusted logger kept honest by auditors who issue challenges. This exposes a structural gap: our design has no auditor role at all — verification is performed by the same device that writes the log. Names the missing party rather than leaving the examiner to find it.

[H8] ✅ Ma, D., Tsudik, G. "A new approach to secure logging." ACM Transactions on Storage, vol. 5, no. 1, art. 2, pp. 1–21, 2009. DOI: 10.1145/1502777.1502779 → Ch2 role: forward-secure sequential aggregate (FssAgg) authentication — tamper-evidence without an online trusted third party or secure hardware. The strongest "you did not need the cloud for this" challenge, and worth a direct answer.

[H9] 🔖 Holt, J. E., Seamons, K. E. "Logcrypt: Forward Security and Public Verification for Secure Audit Logs." Proc. 2006 Australasian Workshops on Grid Computing and e-Research (ACSW Frontiers '06), pp. 203–211, 2006. URL: https://eprint.iacr.org/2005/002 (ACM DL id 10.5555/1151828.1151852) → Ch2 role: separates log creation from log verification — the property our architecture lacks (see [H7]).

[H10] ✅ Laurie, B., Langley, A., Kasper, E. "Certificate Transparency." RFC 6962, IETF, Category: Experimental, ISSN 2070-1721, June 2013. DOI: 10.17487/RFC6962 — header block fetched and read directly from rfc-editor.org → Ch2 role: the blueprint for the required fix. CT does not ask the log to behave — it makes append-only externally checkable through Merkle Tree Heads, signed timestamps, and independent monitors/auditors. This is the precedent for the S3 Object Lock + versioning + server-derived time + version-pinned verification remediation, and the reason a client-side DynamoDB ConditionExpression is insufficient: a credential holder simply omits it. CT assumes the log operator is untrusted; our current design assumes the device is trusted, which it is not.

[H11] ✅ Laurie, B. "Certificate Transparency." Communications of the ACM, vol. 57, no. 10, pp. 40–46, 2014. DOI: 10.1145/2659897 → Ch2 role: the readable companion to [H10] — "public, verifiable, append-only log" in one phrase. Good for the §2.3 framing sentence.

[H12] ✅ Adams, C., Cain, P., Pinkas, D., Zuccherato, R. "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)." RFC 3161, IETF, August 2001. DOI: 10.17487/RFC3161 (updated by RFC 5816) → Ch2 role: the standardised Time Stamping Authority. Defines what a real trusted timestamp requires — which is what defect #1 means we do not have.

[H13] ✅ NIST. Secure Hash Standard (SHS), FIPS PUB 180-4, August 2015 (original March 2012). DOI: 10.6028/NIST.FIPS.180-4 → Ch2 role: normative citation for SHA-256 in §2.3/Ch3, and for P2's 12,160.71 hashes/s being a throughput measurement of a standardised primitive.

4. Lightweight / consensus-free distributed ledgers for IoT

Purpose in Ch2: the terminology-defence section. Why "lightweight hash chain with cloud anchoring" and not "blockchain" — and why dropping consensus is a legitimate design point rather than an incomplete blockchain.

[B1] 🔖 Nakamoto, S. "Bitcoin: A Peer-to-Peer Electronic Cash System." Self-published whitepaper, 31 October 2008. URL: https://bitcoin.org/bitcoin.pdf → Ch2 role: cite only to mark what we are not doing. No proof-of-work, no distributed consensus, no P2P network, no incentive layer, single writer. ◑ Self-published whitepaper with no DOI, venue, or peer review. Flagging because an examiner may object to citing it as a scholarly source — cite it as a primary technical document and lean on [B4]/[B5] for peer-reviewed framing.

[B2] ✅ Liang, X., Shetty, S., Tosh, D., Kamhoua, C., Kwiat, K., Njilla, L. "ProvChain: A Blockchain-Based Data Provenance Architecture in Cloud Environment with Enhanced Privacy and Availability." Proc. 17th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing (CCGrid '17), pp. 468–477, 2017. DOI: 10.1109/CCGRID.2017.8 → Ch2 role: the nearest neighbour in the literature — hash records of data operations into a ledger for tamper-evident provenance, with a low-overhead claim. The sharpest positioning question in Ch2 is what we add over ProvChain. Defensible answers: a real edge device rather than a cloud testbed, n≥30 statistics per attack class, and the N2 cost-equivalent baseline. Not: the architecture.

[B3] ✅ Dorri, A., Kanhere, S. S., Jurdak, R. "Towards an Optimized BlockChain for IoT." Proc. 2nd International Conference on Internet-of-Things Design and Implementation (IoTDI '17), pp. 173–178, 2017. DOI: 10.1145/3054977.3055003 → Ch2 role: explicitly replaces consensus with a centrally managed immutable ledger on constrained devices. The direct precedent for consensus-free-by-design, and the reason our framing is a recognised position rather than a shortcut.

[B4] ✅ Dorri, A., Kanhere, S. S., Jurdak, R., Gauravaram, P. "LSB: A Lightweight Scalable Blockchain for IoT security and anonymity." Journal of Parallel and Distributed Computing, vol. 134, pp. 180–197, 2019. DOI: 10.1016/j.jpdc.2019.08.005 → Ch2 role: the peer-reviewed "lightweight blockchain" benchmark. Their overhead methodology is the model our P1–P4 measurements should be compared against in §2.6.

[B5] ✅ Reyna, A., Martín, C., Chen, J., Soler, E., Díaz, M. "On blockchain and its integration with IoT. Challenges and opportunities." Future Generation Computer Systems, vol. 88, pp. 173–190, 2018. DOI: 10.1016/j.future.2018.05.046 → Ch2 role: survey support for the claim that full blockchain is too heavy for edge devices — needed for Problem Statement part 2 (Ch1 §1.2) and §2.4.

[B6] ✅ Androulaki, E., Barger, A., Bortnikov, V., Cachin, C., Christidis, K., et al. "Hyperledger Fabric: a distributed operating system for permissioned blockchains." Proc. 13th EuroSys Conference (EuroSys '18), Porto, pp. 1–15, 2018. DOI: 10.1145/3190508.3190538 — Crossref-confirmed → Ch2 role: the permissioned mid-point between Bitcoin and our single-writer chain. Lets §2.4 present a spectrum (permissionless → permissioned → single-writer + anchor) and locate this work on it deliberately.

[B7] ✅ Medhane, D. V., Sangaiah, A. K., Hossain, M. S., Muhammad, G., Wang, J. "Blockchain-Enabled Distributed Security Framework for Next-Generation IoT: An Edge Cloud and Software-Defined Network-Integrated Approach." IEEE Internet of Things Journal, vol. 7, no. 7, pp. 6143–6149, July 2020. DOI: 10.1109/JIOT.2020.2977196 → Ch2 role: edge-cloud blockchain security framework — a direct comparator row in the §2.6 table. Harvested from the abandoned draft (its ref [22]) and independently re-verified — see §6.

[B8] ✅ Rahman, M. S., Chamikara, M. A. P., Khalil, I., Bouras, A. "Blockchain-of-blockchains: An interoperable blockchain platform for ensuring IoT data integrity in smart city." Journal of Industrial Information Integration, vol. 30, art. 100408, 2022. DOI: 10.1016/j.jii.2022.100408 → Ch2 role: IoT data integrity in a smart-city hierarchy — same problem statement, much heavier machinery. Good contrast for the overhead argument. Harvested from the abandoned draft (its ref [25]) and independently re-verified — see §6.

5. Edge constraints and overhead measurement

Purpose in Ch2: justify measuring overhead at all, and give P1–P4 a methodological lineage.

[E1] ✅ Shi, W., Cao, J., Zhang, Q., Li, Y., Xu, L. "Edge Computing: Vision and Challenges." IEEE Internet of Things Journal, vol. 3, no. 5, pp. 637–646, 2016. DOI: 10.1109/JIOT.2016.2579198 — Crossref-confirmed → Ch2 role: the standard definition-and-motivation citation for edge computing; supports the data-minimisation-on-the-integrity-path framing (hashes travel, not frames).

[E2] ✅ Satyanarayanan, M. "The Emergence of Edge Computing." Computer, vol. 50, no. 1, pp. 30–39, 2017. DOI: 10.1109/MC.2017.9 — Crossref-confirmed → Ch2 role: bandwidth and privacy rationale for processing at the edge.

[E3] ✅ Roman, R., Lopez, J., Mambo, M. "Mobile edge computing, Fog et al.: A survey and analysis of security threats and challenges." Future Generation Computer Systems, vol. 78, pp. 680–698, 2018. DOI: 10.1016/j.future.2016.11.009 — Crossref-confirmed → Ch2 role: edge-specific threat analysis. Supports the Ch3 §3.1.1 threat model, including the point that physical/local access to an edge node is a realistic assumption — which is what makes defect #2 a real finding rather than a technicality.

[E4] ✅ Süzen, A. A., Duman, B., Şen, B. "Benchmark Analysis of Jetson TX2, Jetson Nano and Raspberry PI using Deep-CNN." Proc. 2020 International Congress on Human-Computer Interaction, Optimization and Robotic Applications (HORA), 2020. DOI: 10.1109/HORA49412.2020.9152915 — Crossref-confirmed → Ch2 role: published Jetson Nano CPU/RAM/power baselines, so our P1/P4 numbers (CPU 0.58%, RAM drift +0.63 MB over 23.22 h) sit against an external reference point instead of standing alone.

6. Audit of the abandoned Draft Thesis.pdf

Path correction — flagging a documentation conflict, not picking silently. SONNET_TASK_PLAN.md (Working files) points at C:\Users\ASUS\Desktop\Draft Thesis (Introduction & Literature Review).pdf. That is not the file the 2026-07-29/30 session audited. There are two different documents:

The session-log findings are reproducible only in the Downloads file, and both were re-confirmed there directly:

• ✅ its ref [22] is Medhane et al. (blockchain-enabled distributed security framework), so an in-text "Schinckus [22]" is genuinely misaligned;
• ✅ its ref [19] carries the placeholder DOI https://doi.org/10.1007/springerURL.

CLAUDE.md's session log is accurate; SONNET_TASK_PLAN.md's path pointer is stale and should be corrected to the Downloads path (or the Desktop file marked as a superseded earlier draft).

Harvest outcome. 80 of ~112 entries were machine-reconstructed into harvest_pool.txt (scratchpad). The pool is dominated by 6LoWPAN, blockchain-SDN, blockchain-IoT surveys, and generic computer-vision applications — the abandoned approach. Three entries were relevant enough to keep, and each was verified by independent search rather than trusted from the draft: [V7], [B7], [B8].

Not one of Haber & Stornetta, Bayer/Haber/Stornetta, Merkle, Schneier & Kelsey, Crosby & Wallach, Certificate Transparency / RFC 6962, RFC 3161, ProvChain, PKLot, or CNRPark-EXT appears anywhere in that draft. The entire §3 lineage above — the part that decides the viva — is new work. This is consistent with the earlier assessment and is the concrete reason the old draft's structure cannot be reused.

No prose or structure from either draft has been reused.

7. Not cited — could not verify, or verified and rejected

Recorded so these are not silently re-introduced later.

Verified as real but deliberately excluded:

• IOTA / "The Tangle" (Popov). Frequently cited for feeless DAG-based IoT ledgers, but the canonical reference is a versioned self-published whitepaper whose content and version history are unstable, and the original construction has been materially superseded. Excluded on citability grounds. If §2.4 needs a DAG comparator, a peer-reviewed analysis should be sourced instead — open gap.

Fields that remain unconfirmed (entry still usable, field marked):

• [H3] Merkle 1980 — no DOI located; pages "122" vs "122–134" disagree across secondary sources. Needs a look at the actual 1980 IEEE S&P proceedings.
• [B1] Nakamoto 2008 — no DOI/venue/peer review by nature.

Corrected during verification (guessed values that proved wrong):

• Huang et al. 2013 — DOI 10.1109/TCSVT.2013.2249397 (my inference) returned 404; the correct DOI is 10.1109/TCSVT.2013.2254961, confirmed via Crossref. Recorded as a reminder that inferred DOIs must always be resolved.
• Satyanarayanan 2017 — two DOIs appeared in search results (10.1109/MC.2017.9 and 10.1109/mc.2017.3641639); 10.1109/MC.2017.9 is the one that resolves to the correct record in Crossref.

Nothing was substituted for anything that could not be found.

8. Gaps to close before Ch2 is written

Honest list of what §2 still needs, in priority order:

1. A peer-reviewed source for "the hash chain must be archived / pruned." Ch5 raises the >100k-block verification cost (≈8 s for the live chain); [H2] and [H7] cover pruning/efficiency, but a dedicated citation would be stronger.
2. A DAG / feeless-IoT-ledger comparator to replace the excluded IOTA whitepaper.
3. Empirical SHA-256 throughput on ARM/embedded — [E4] covers CNN workloads, not hashing. P2's 12,160.71 hashes/s currently has no external comparator.
4. Append-only object storage as an integrity control (S3 Object Lock / WORM / write-once media). Needed to support the remediation in Ch3 §3.5.6 and Ch5 §5.4.5 with more than vendor documentation.
5. §2.6 comparison table — columns per SONNET_TASK_PLAN.md T4.2: platform, integrity technique, real attack evaluation?, overhead measured?, statistical n. Populate from [B2], [B4], [B7], [B8], [V3]. Most will be blank in the "statistical n" column, which is the gap this thesis claims to fill — verify that claim honestly per paper before asserting it.
6. Malaysian / regional smart-parking context if the introduction wants it (USM framing). None sourced yet.

Verification methods used

• api.crossref.org/works/{DOI} — DOI resolved, returned metadata matched (marked Crossref-confirmed: [V2], [V4], [B6], [E1], [E2], [E3], [E4])
• rfc-editor.org — RFC 6962 header block fetched and read verbatim
• dblp.org — page numbers for [H7]
• Publisher/proceedings pages (ScienceDirect, Springer, ACM DL, IEEE Xplore, USENIX) and targeted web search returning title + venue + year + authors for the remainder

Count: 36 verified references (7 Layer 1, 4 attack surface, 13 integrity, 8 lightweight-ledger, 4 edge/overhead) — clears T4.1's "30+ real references" bar.

Project README

1,100 words · source README.md

MSc Thesis — Edge-Based Smart Parking Security

A Multi-Layer Security Framework for Edge-Based Smart Parking with Lightweight Hash Chain Integrity Verification and Cloud Anchoring

Universiti Sains Malaysia · Nazirul Hafiz · target submission ≥ Dec 2026

A three-layer security framework on an NVIDIA Jetson Nano: Canny-based occupancy detection (Layer 1), edge-local processing with data minimisation on the integrity path (Layer 2), and a consensus-free SHA-256 hash chain with AWS DynamoDB cloud anchoring (Layer 3). Evaluated with 14 experiments plus 2 control experiments, n ≥ 30 each.

Terminology. "Lightweight hash chain with cloud anchoring". The word "blockchain" appears only as "blockchain-inspired" when comparing with literature. This is not a blockchain — there is no consensus.

Read this first

Source-of-truth order when numbers conflict: fresh CSVs from the Jetson → SONNET_TASK_PLAN.md tables → chapter .md files → dashboard. Never correct a chapter to match the dashboard; the flow is always CSV → thesis → dashboard.

Thesis status

Ch 5 cannot be finalised until E10 and the Layer 1 accuracy evaluation land. Ch 6 cannot be honestly written until the anchoring hardening is resolved — that determines whether the conclusion reads "we found a limitation" or "we found it and closed it".

Results (all traced to CSVs in data/)

Known defects — stated, not hidden

Three boundary failures are documented in the thesis rather than papered over. Two are open.

1. anchored_at is client-generated (cloud_anchor.py, datetime.utcnow()). DynamoDB does not timestamp items. The cloud anchor provides no independent time reference against a device-level attacker. (Written up; fix open.)
2. The threat-model boundary does not hold. The device holds IAM PutItem credentials, and upload_checkpoint() issues an unconditional put_item, so an in-scope device attacker can overwrite checkpoints. Against this thesis's own primary adversary the anchor currently gives zero guarantee. Fix: append-only enforced by the storage service (S3 Object Lock + versioning), server-derived time, version-pinned verification, then re-run E6/E7. A client-side DynamoDB ConditionExpression is insufficient — a credential holder can simply omit it. (Open.)
3. ROI mask-boundary artefact in Layer 1. detect_status() masks before running Canny, so each ROI outline becomes a hard black/content edge. Measured on a blank frame: mean 234 edge px (78% of the 300 threshold), r = 0.995 with polygon perimeter, 4 of 14 slots read "occupied" on an empty image. Running Canny first and masking the edge map removes it entirely. Across 1,400 slot-readings the fix flips 334 verdicts (23.9%), all occupied→empty, none the other way. (Measured; deploy decision open.)

Configuration (rois.json, Canny threshold) is not covered by block_hash — an in-scope attacker can shift a polygon and every later detection is wrong but faithfully recorded. Either scope it out explicitly or bind a config digest into the chain. (Undecided.)

Layout

chapter{3,4,5}_*.md abstract.md   thesis chapters
data/*.csv                        experiment results (source of truth)
blind_labeling/                   100 frames + labeling_blind.csv  ← USER labels this
layer1_verdicts/                  ⚠ system verdicts — DO NOT OPEN until labelling done
blockchain.py cloud_anchor.py     core implementation
parking_detector.py               live detector (Jetson canonical)
run_*.py benchmark_*.py           experiment harnesses
measure_roi_edge_artifact.py      L1: quantifies the Canny masking artefact
generate_layer1_verdicts.py       L2: dual-detector verdicts for the labelling set
build_thesis_site.py              renders chapters → tabbed HTML

Machines

• Jetson — ssh jetson; production parking_detector.py + chain.db (DOWN since 2026-04-29). Never write without explicit per-session confirmation.
• AWS — boto3 via the Jetson (aws CLI is not installed; WSL ~/.aws is invalid). DynamoDB parking_blockchain / parking_frames, S3 parking-detection-frames.
• Sites — dashboard https://master.nazirulhafiz.dev · thesis https://parking-thesis.pages.dev. Both Cloudflare Pages, noindex, deployed from a local dist/ (not from GitHub).

Rebuild + redeploy the thesis site:

py -3 build_thesis_site.py
npx wrangler pages deploy site_dist --project-name parking-thesis --branch main

Outstanding

User only - Change the RTSP camera password — still unchanged, was public for months, and remains in 7 commits of the dashboard repo's history. - Label blind_labeling/ (ground_truth only, blind). One pass scores both detectors. - E10 field session — see E10_field_session_runsheet.md.

Decisions - Deploy the corrected detect_status() to the Jetson? - Bind config into the chain, or scope it out? - RO3 wording (E10 is n=0, so 9 of 10 conducted) and RO4 (23.22 h ≠ 24 h).

Work - AWS Object Lock hardening + re-run E6/E7 — the load-bearing item. - Ch 2 literature review — longest pole. Must engage Haber & Stornetta (1991), Schneier & Kelsey, Crosby & Wallach, Certificate Transparency (RFC 6962), ProvChain, PKLot / CNRPark-EXT. None of these appear in the abandoned Draft Thesis.pdf, whose in-text citations are also systematically misaligned with its own reference list — harvest references from it only after verification; do not reuse its prose. - Then Ch 1, Ch 6, front matter, ⛔ Checkpoint 3.

Execution Plan

4,085 words · source SONNET_TASK_PLAN.md

Thesis Execution Plan — for Sonnet 5

Role division: Sonnet 5 executes the tasks below. Fable 5 reviews at each checkpoint (user switches model with /model, pastes/points to the output, Fable checks). Do NOT skip checkpoints — stop after each phase and tell the user to run the Fable review before continuing.

Context: Master's thesis — three-layer security framework for edge-based smart parking on Jetson Nano. The main contribution is a lightweight SHA-256 hash chain with AWS DynamoDB cloud anchoring (consensus-free; NOT a full blockchain). Approved framing decisions (already evaluated by Fable, do not re-litigate): - Language: English throughout (dual-language abstract BM+BI at the end, USM format). - Terminology: "lightweight hash chain with cloud anchoring". The word "blockchain" only as "blockchain-inspired" when comparing with literature. New title: A Multi-Layer Security Framework for Edge-Based Smart Parking with Lightweight Hash Chain Integrity Verification and Cloud Anchoring. - E6 (53%): keep the data, discuss honestly as a limitation (scenario D hard case, cloud anchor timestamp partially mitigates). Do NOT claim >95%. - P4: rerun for a full 24 hours on the Jetson (task below). Until the rerun completes, all text must say 4.85 hours. - P1: report as "no statistically significant CPU overhead (t=1.99, p=0.056)" — never as "negative overhead".

Working files

• All chapter drafts: C:\Users\ASUS\Downloads\parking_system\ (WSL: /mnt/c/Users/ASUS/Downloads/parking_system/)
• Experiment CSVs / chain data live on the Jetson: ~/parking_security/data/ — reach it with ssh jetson (works from WSL, Cloudflare tunnel)
• Do NOT touch or reuse anything from C:\Users\ASUS\Desktop\Draft Thesis (Introduction & Literature Review).pdf — that is the abandoned old approach (6LoWPAN/streetlight/consensus) and its citations are unverified/likely fabricated.

Real experiment numbers (source of truth)

Per-sub-type breakdowns (e.g., E1 1-pixel vs 10-pixel vs Gaussian) are in the CSVs on the Jetson (~/parking_security/data/). Pull them before filling Chapter 5's sub-tables. If a CSV lacks a breakdown, aggregate rows only and note it.

Verified facts (checked by Fable directly, 2026-07-03 — these override earlier notes)

• Slot count = 14 (confirmed in rois.json both local and Jetson). Ch3 §3.3.1 and Ch4 say 15 — wrong, fix to 14. (T1.2 pre-resolved.)
• Master results table verified against ~/parking_security/data/master_results_table.txt on the Jetson. Corrections vs the table above:
• P1 CPU 95% CI is [−15.87, −0.12], p=0.056188 (not [−16.21,+0.22]).
• P3 detail: mean verify 132.88 ms, slope 0.039934 ms/block, R²=0.9998.
• E7 master-table latency row shows 0.00 — the 13.40 ms figure needs verification from E7_chain_rewrite.csv (it likely records rewrite-time-vs-K, which is what Ch5 Table 5.7 needs). Pull the CSV before filling.
• P4 labeled "24hr" in the table but actual run was ~4.85 hr (30 samples × 10 min) — rerun task T3.1 stands.
• E10 has n=0 — the template CSV was never filled. USER DECISION (2026-07-03): RUN IT. Added as T3.3 below. Until its data exists, leave Ch5 §5.2.10 marked "pending — field session scheduled" and never present E10 as completed.
• AWS verified live (via boto3 on the Jetson; aws CLI is NOT installed on the Jetson, and WSL's ~/.aws credentials are INVALID — always query AWS through boto3 over ssh jetson):
• parking_blockchain: ACTIVE, ~25,923 checkpoint items
• parking_frames: ACTIVE, ~259,229 items
• S3 bucket has frames/ + status.json, attack_result.json, command.json
• Live chain has exceeded block_index 211,860 (chain.db = 133 MB as of Apr 29)
• Bonus material for the thesis: the live deployment (>200k blocks, ~259k frames, weeks of continuous anchoring) is real longitudinal evidence — cite it in Ch5 §5.4 (Edge Device Suitability) and Ch6. Also note: at 0.04 ms/block, full verification of the live 200k-block chain ≈ 8 s — concrete support for the chain-archiving limitation/future-work point.
• E7 resolved (from E7_chain_rewrite.csv, verified): CSV has full per-K data — rewrite_time_ms means ≈ 0.49 (K=10), 2.43 (K=50), 4.35 (K=100), 20.17 (K=500), 39.58 (K=1000); 6 trials each; detected=0 in all rows (local verification passes after rewrite, by design); verify_after_ms ≈ 39 ms constant. The earlier "13.40 ms" figure = grand mean rewrite time across all 30 trials. Ch5 Table 5.7 can be filled per-K directly from this CSV. Linearity ≈ 0.039 ms/block, consistent with P3 slope. K=10 target (<1000 ms) met by 3 orders of magnitude.
• P4 duration confirmed from CSV timestamps: 2026-04-13 07:46 → 12:37 = 4.85 hours, 30 samples at 10-min intervals, chain 11→301 blocks, all valid. The "24hr" in filenames/labels is aspirational only. T3.1 rerun stands.
• ⚠️ Live system is DOWN: ps on the Jetson shows only jtop running — parking_detector.py and attack_demo.py are NOT running (chain.db and logs last written 2026-04-29). The dashboard "live demo" is currently on simulation fallback. Before the viva/demo, both scripts must be restarted on the Jetson. Add a demo-day checklist item; optionally restart them when running T3.1 (ask user first — T3.1's P4 measurement may want the detector either on or off depending on the original P4 protocol; check run_P4_stability.py before deciding).
• Local backup gap: attack_demo.py exists on the Jetson but is missing from C:\Users\ASUS\Downloads\parking_system\. Copy it over during Phase 2 so the laptop backup is complete.

Code-level findings (Fable read the actual source on the Jetson, 2026-07-03)

• Canny pixel threshold mismatch: Ch3 §3.3.2 says "exceeds 500" but parking_detector.py detect_status() uses > 300 (changed 2026-04-14 because 500 missed cars). Fix Ch3 to 300 and add one sentence noting it was recalibrated empirically. Add to T1 list.
• ⚠️ P4 rerun hazard — read before running T3.1: run_P4_stability.py sets DB_PATH = data/chain.db (the LIVE chain) and appends 10 synthetic blocks per sample ("simulate real usage"). Rerunning it as-is would inject 300 fake blocks into the live 200k-block production chain. Before the 24h rerun: change DB_PATH to a fresh test DB (e.g. data/p4_chain_24h.db) and set SAMPLE_INTERVAL = 2880. Never point it at the live chain.db.
• Related historical note: the Apr-13 P4 run used chain.db when it was fresh (chain grew 11→301), so the live chain's first ~300 blocks are synthetic sim blocks from that run. Not a validity problem, but be accurate in Ch5 §5.4 when describing the live deployment (say ">200,000 blocks accumulated during continuous operation", don't claim every block is a camera frame).
• E6 failure mechanism now fully explained (use this in Ch5 §5.2.6 Discussion): verify_chain() checks only (1) self-integrity (block_hash == recomputed) and (2) linkage (previous_hash). In attack_replay(), scenarios A/B keep the original block_hash while block_index/previous_hash changed → self-integrity check fails → detected (16/30). Scenarios C/D recompute the block_hash after replaying → the chain is internally consistent → undetected locally (14/30). 16/30 = 53.3% exactly matches the data. Local verification has no timestamp monotonicity or content-freshness check; detecting C/D requires the cloud anchor's independent anchored_at timestamp or a nonce/sequence scheme (→ future work). This is the honest, mechanistic explanation the examiner will want.
• E1 sub-types are hash-level simulations: attack_frame_modification() doesn't actually modify pixels; it replaces the stored frame_hash with a hash of different random bytes (sizes 50,001 / 50,010 / 51,000 for "1pixel/10pixel/gaussian"). Ch5's existing wording ("simulated by altering the stored frame hash") is accurate — keep that phrasing; do NOT describe it as actual pixel manipulation.
• Detector code matches Ch4 description otherwise: 1020×600 resize, 5 s interval, auto-reconnect, headless mode, keyboard controls only when not headless, checkpoint every 10 blocks, status.json upload for the dashboard. build_test_chain() in tamper_simulator.py uses a synthetic chain in a temp DB — consistent with the "attacks run on synthetic chain" viva note.

PHASE 1 — Consistency fixes (do first, ~1 session)

T1.1 — Fix abstract.md: - E6 sentence: replace the ">95% target" claim with honest wording (53% combined; scenario-dependent; cloud anchor covers timestamp-based replay variants). - P4: "24-hour" → actual duration (4.85 hours) until T3.1 rerun completes. - P1: rephrase to "no statistically significant CPU overhead". - P2: report the real number (12,160 h/s), not just ">100/s". - Terminology sweep: "lightweight SHA-256 hash chain (blockchain-inspired)" framing; title updated.

T1.2 — Slot count verification: read rois.json (local copy and/or Jetson), count polygons. Fix Ch3 (§3.3.1) and Ch4 (§4.2.1, §4.4) to the true number (14 vs 15 discrepancy).

T1.3 — Terminology sweep across chapter3_methodology.md and chapter4_implementation.md: blockchain → lightweight hash chain (keep "blockchain-inspired" where comparing to literature). Section titles too (e.g., 3.5, 4.5).

T1.4 — Add threat model subsection to Chapter 3 (new §3.1.1 or inside §3.6): attacker capabilities assumed (read/write access to stored chain and frames, network MITM, camera substitution; NOT compromise of AWS account or the running process), and what is out of scope. Keep it ~1 page.

⛔ CHECKPOINT 1: stop. Ask user to switch to Fable to review Phase 1 diffs before continuing.

✅ CHECKPOINT 1 PASSED (Fable review, 2026-07-03)

Phase 1 verified against actual file state: no leftover "blockchain" prose (identifiers correctly preserved), no leftover 15-slot or 500-threshold, threat model correctly placed as §3.1.1, abstract E6/E7/P1 wording accurate against code analysis and CSVs. Approved to proceed to Phase 2. Deferred style nits for Phase 6 polish (non-blocking): 1. Abstract has grown past ~550 words — check USM's abstract word limit at front-matter stage and trim if needed. 2. Ch4 §4.9 sentence "The hash chain layer is implemented as a local, blockchain-inspired hash chain" is redundant — rephrase once. 3. Abstract phrase "per completed experiment" is awkward — revisit when the two [PENDING] markers are cleared. 4. Ch3 §3.6.4 P4 design text (24 h, 48-min sampling) describes the intended protocol, which will only match reality after the T3.1 rerun — Ch5 must state explicitly which protocol produced whichever P4 dataset it reports.

PHASE 2 — Chapter 5 completion (~1–2 sessions)

T2.1 — Pull experiment CSVs from Jetson (ssh jetson, ~/parking_security/data/) to the local folder. List what exists first; copy via scp/cat.

T2.2 — Fill all tables in chapter5_results.md (5.2.1–5.2.11, 5.3.1–5.3.4) from the CSVs + the source-of-truth table above. Compute missing SD/CI from raw data where needed (Wilson score for proportions, t-interval for means). Never invent a number — if raw data is missing for a cell, mark it "not recorded" and flag it in the checkpoint summary.

T2.3 — Write Discussion paragraphs for each experiment. E6 and E7 get the longest treatment: - E6: why scenario D (updated timestamp + recomputed hash) evades local verification; which scenarios the cloud anchor catches; limitation framing. - E7: local rewrite is undetectable by self-verification by design — this motivates the cloud anchor; report rewrite-time linearity as computational deterrent.

T2.4 — Write §5.4 (Overall Discussion) and §5.5 Summary using the four existing sub-headings.

⛔ CHECKPOINT 2: Fable reviews Chapter 5.

⚠️ CHECKPOINT 2: PASSED WITH REQUIRED FIXES (Fable review, 2026-07-03)

Chapter 5 numbers verified against raw CSVs — all tables correct, E10/P4 honestly marked pending, E6/E7 discussions accurate against tamper_simulator.py. However, Fable read run_advanced_experiments.py (previously unread) and found the E8/E9 discussion misattributes the detection mechanisms, plus one statistical-coherence problem. Apply these 3 fixes FIRST, before starting Phase 3 tasks:

F1 — §5.2.9 E9 Discussion is WRONG about the mechanism. The code's detected column comes from a timestamp-gap heuristic (scan consecutive blocks; gap > 3600 s → flagged), NOT from the self-integrity check. The CSV's separate chain_valid=0 column shows self-integrity also fails (since block_hash covers timestamp and the attack does not recompute it) — so E9 is caught by two independent mechanisms, but the reported detection metric is the gap heuristic. Rewrite the Discussion to: (a) attribute the recorded 100% to gap analysis (this matches Ch3's original design note "Primary detection: timestamp gap > 1 hour"), (b) note chain_valid = 0 in all 30 trials as evidence the self-integrity check independently catches it, (c) keep the E6 contrast. Also consider adding a chain_valid column to Table 5.9.

F2 — §5.2.8 E8 Discussion, minor precision. Detection is a repeated-hash frequency scan (max_repeat > 5 → suspicious); the recorded latency_ms is the timing of the subsequent full-chain verify_chain() pass (chain remains structurally valid → full traversal ≈ 39 ms), not the latency of the repeated-hash scan itself. Reword so the latency column isn't presented as the detection mechanism's own latency; state the >5 threshold explicitly.

F3 — P1 CI/t-test coherence (examiner trap). Table 5.12's CPU CI [−15.87, −0.12] uses z = 1.96 and excludes zero, while the t-test (crit t(29) = 2.045) says not significant — an examiner will spot this contradiction. Fix: report t-based CIs for the paired P1 comparisons: CPU [−16.21, +0.22], RAM [−0.05, +0.17], FPS [−5.79, −4.82] (now the CPU CI includes 0, consistent with p = 0.056), and add a sentence to §5.1 stating paired-comparison CIs use the t-distribution (df = 29). Separately, Table 5.13's P2 CI [12,146.45, 12,174.97] was computed with t but §5.1 declares z — change to the z-based [12,147.04, 12,174.38] to match the stated methodology (and the master table).

Non-blocking notes: E1 and E9 share identical random target indices (both seeded with 42) — harmless coincidence, no action; §5.4.2 "four orders of magnitude" (vs capture demand) and abstract's "two orders" (vs 100/s target) are different comparisons, both correct as written.

PHASE 3 — Long-running / hardware tasks (start early, run in parallel)

T3.1 — P4 24-hour rerun: on Jetson via ssh jetson, launch run_P4_stability.py for a full 24 h (nohup/background; confirm sampling interval gives ≥30 samples). Check parking_detector.py / attack_demo.py won't conflict (ask user if unsure whether to pause them). When done, update P4 numbers in abstract + Ch5.

T3.2 — Layer 1 accuracy evaluation (closes a viva hole): 1. Write a small script to sample 100 frames from S3 (parking-detection-frames) across different times of day. 2. Have the USER label ground truth (occupied/empty per slot) — prepare a simple labeling aid (CSV template or minimal HTML page). Do not label on the user's behalf. 3. Compute accuracy/precision/recall vs the detector's recorded results; add one table + short paragraph to Ch3 or Ch5.

T3.3 — E10 field session (user decided: RUN IT — combine with T3.2 labeling in ONE car-park visit): 1. Prepare beforehand: a printed run-sheet from E10_physical_spoofing_template.csv (6 object types × 5 trials: white poster, dark tape car outline, cardboard box, reflective surface, plastic bag, tree branch debris), and a live view of detection output (dashboard or status.json) so the user can read the system's verdict per trial on their phone. 2. The USER physically places each object in an empty monitored slot; Sonnet (or the user) records per trial: object type, slot ID, system verdict (occupied/empty), ground truth (empty), → false positive yes/no. 3. Make sure parking_detector.py is RUNNING on the Jetson before the visit (it is currently DOWN — restart it first) and confirm status.json updates every 5 s. 4. Afterwards: fill the CSV, compute FP rate + Wilson CI, fill Ch5 §5.2.10 including the framing note that E10 tests Layer 1 limits while the hash chain records results faithfully regardless.

Phase 3 progress (Sonnet, 2026-07-03)

• F1–F3 (Checkpoint 2 fixes) applied to chapter5_results.md: E9 discussion now correctly attributes detection to the timestamp-gap heuristic in run_advanced_experiments.py (with chain_valid=0 noted as independent corroboration from self-integrity); E8 discussion now correctly attributes detection to the repeated-hash frequency scan (max_repeat > 5) and clarifies the reported latency is the subsequent full verify pass, not the scan itself; P1 CIs switched to t-based ([−16.21,+0.22] CPU, [−0.05,+0.17] RAM, [−5.79,−4.82] FPS — CPU/RAM now correctly span zero, consistent with non-significance) and P2 CI switched to z-based [12,147.04, 12,174.38], with a methodology sentence added to §5.1 explaining which convention applies where.
• T3.1: P4 24-hour rerun launched on Jetson via a NEW script run_P4_stability_24h.py (does not modify/overwrite the original run_P4_stability.py, which remains the historical record of the 4.85h run). Uses an ISOLATED test DB (data/p4_chain_24h.db), SAMPLE_INTERVAL=2880s (48 min × 30 = 24h), output to data/P4_stability_24hr_full.csv. Confirmed running independently on the Jetson (PID visible via ps, first sample logged) — will complete ~24h after 2026-07-03 18:05 (Jetson local time). chain.db (production) untouched.
• T3.2: Built sample_frames_for_labeling.py (runs on Jetson — has boto3/cv2/rois.json). Scans parking_frames DynamoDB table (~259k records), stratified-samples ~100 frames across hour-of-day buckets for lighting diversity, downloads each frame from S3, overlays the 14 ROI polygons + slot IDs + the system's own recorded verdict (green=empty, red=occupied) directly on the image, and produces labeling_template.csv pre-filled with system_detected_status per slot and a blank ground_truth column. This turns Layer 1 accuracy labeling into a fast confirm/correct task rather than blind labeling. The user must do the actual labeling — not automated. Launched in background; completion status appended below once confirmed.
• T3.3: E10_field_session_runsheet.md created — pre-visit checklist (including restarting parking_detector.py, which has been down since 2026-04-29), trial procedure, fillable 30-row run-sheet, and post-visit instructions for transferring data into the real E10_physical_spoofing_template.csv. Did not restart the live detector yet — that's step 1 of the run-sheet, to be done by the user immediately before the actual field visit, not preemptively.

✅ T3.1 & T3.2-prep COMPLETE — P4 24h stats verified by Fable (2026-07-04)

P4 24-hour rerun finished and verified from raw CSV (data/P4_stability_24hr_full.csv, pulled to laptop). Sonnet: plug these into Ch5 §5.3.4 (replace the 4.85h preliminary tables/discussion, keep the 4.85h run mentioned as an initial pilot) and clear the two [PENDING] markers about P4 in abstract.md:

• Protocol: 30 samples × 48-min interval; first→last sample span 23.22 h (report as "24-hour protocol (23.2 h between first and last samples)")
• Run window: 2026-07-03 10:05 UTC → 2026-07-04 09:19 UTC, isolated test DB (p4_chain_24h.db), production chain untouched
• CPU: mean 0.58%, SD 0.25, range 0.3–1.2, slope +0.0145 %/sample — stable
• RAM: mean 29.90 MB, SD 0.14, range 29.54–30.17, slope +0.0133 MB/sample (criterion < 1 MB/sample — MET), total drift +0.63 MB over ~24 h — report the small upward drift honestly; it is two orders of magnitude below the leak criterion
• Chain: 11 → 301 blocks, all 30 samples valid; verify_ms grew 0.60 → 14.16 ms linearly with chain length (consistent with P3 slope)
• Abstract wording suggestion: "a 24-hour stability test (P4) revealed no memory leak (RAM drift +0.63 MB over 24 h, slope 0.013 MB/sample) and no CPU drift"

T3.2 labeling package ready (verified on Jetson): 100 annotated frames in ~/parking_security/data/label_frames/ + labeling_template.csv (1,400 slot-rows = 100 frames × 14 slots). USER ACTION REQUIRED: copy to laptop, label ground truth per slot (green box = system said empty, red = occupied). Sonnet: help the user pull the folder to the laptop when asked, then compute accuracy/precision/recall from the completed CSV.

✅ T3.2b regeneration COMPLETE (Sonnet, 2026-07-11): regenerate_blind_labeling.py created and run on the Jetson (read-only S3 downloads only; label_frames/, labeling_template.csv, chain.db, DynamoDB untouched). Results, all verified: 1. Re-rendered all 100 frame IDs (same set as labeling_template.csv) with a NEUTRAL yellow-only overlay (14 ROI polygons + slot labels) — zero exact-pixel-match to the original verdict colors (0,0,255 red / 0,255,0 green) confirmed programmatically on 2 spot-checked images. 2. labeling_blind.csv (1400 rows, header frame_id,annotated_image,slot_id,ground_truth,notes — no verdict column) and system_verdicts.csv (1400 rows, frame_id,slot_id,system_detected_status) written on the Jetson; full 1400-key join-alignment verified equal between the two. 3. compute_layer1_accuracy.py updated (local repo copy) to take both CSVs as args and join on (frame_id, slot_id) at scoring time; smoke-tested against the still-unlabeled blind CSV (correctly reports 1400/1400 blank). 4. label_frames_blind/ (100 images) + labeling_blind.csv copied to the laptop under blind_labeling/. system_verdicts.csv deliberately kept Jetson-only — user labels blind, do not peek at system_verdicts.csv until after labeling. 5. README_LABELING.md update — not done, not in this task's explicit scope; still open if the user wants it. 6. Ch5 note (67.6% system-occupied rate, 946/1400) still applies once accuracy is computed — carry forward.

Still pending before Checkpoint 3 review: user labels the 100 frames BLIND (blind_labeling/, using ground_truth column only — do NOT reference the old labeling_template.csv's system_detected_status), user runs the E10 field session (T3.3 run-sheet ready).

✅ P4 doc updates COMPLETE (Sonnet, 2026-07-10): chapter5_results.md §5.3.4 now reports the full 24-hour confirmation run (Table 5.16b/5.17) alongside the 4.85h pilot (Table 5.16a, kept as initial run); §5.1 status note, §5.4.2, §5.4.4, and §5.5 updated to drop stale "P4 pending" language. abstract.md: both [PENDING] markers cleared — the E10 marker reworded to reference only T3.3, the P4 marker replaced with the verified 24h figures (23.2h span, CPU mean 0.58%, RAM drift +0.63 MB). Dashboard untouched.

⛔ CHECKPOINT 3: Fable reviews accuracy table + updated P4 + E10 results.

PHASE 4 — Chapter 2: Literature Review (~2 sessions)

T4.1 — Collect 30+ REAL references via WebSearch/WebFetch. Every reference MUST be verified to exist (found title + venue + year + authors from an actual search result). Record each in references.md with URL/DOI. Absolutely no fabricated or "plausible-sounding" citations — this project was already burned once by a fake-citation draft. Search areas: (a) vision-based smart parking; (b) attacks on video surveillance integrity; (c) hash chains / secure logging / trusted timestamping (include the classic Schneier & Kelsey line of work); (d) lightweight/consensus-free blockchain for IoT; (e) edge computing security overhead measurements; (f) Jetson-class embedded security benchmarks.

T4.2 — Write Chapter 2 to this structure: 2.1 smart parking & vision detection → 2.2 attack taxonomy on video/sensor integrity (must map to E1–E10) → 2.3 integrity techniques: hash chains, secure logging, timestamping → 2.4 lightweight blockchain for IoT + the terminology-defence paragraph (Fable provided approved wording — ask user for it or find it in fable_review_prompt.md context) → 2.5 edge constraints & overhead studies → 2.6 research gap + comparison table (columns: platform, integrity technique, real attack evaluation?, overhead measured?, statistical n).

⛔ CHECKPOINT 4: Fable reviews Ch2 + spot-checks references.

PHASE 5 — Chapter 1, Chapter 6, front matter (~2 sessions)

T5.1 — Chapter 1 per approved outline: 1.1 Background → 1.2 Problem Statement (three-part: no integrity guarantees in current systems; full blockchain too heavy for edge; lack of empirical evidence for lightweight mechanisms) → 1.3 three objectives (approved wording exists in Fable's Langkah 6 output — reuse it) → 1.4 RQs 1:1 with objectives → 1.5 Scope & Limitations (single device, threat model reference, Layer 1 as carrier application) → 1.6 Contributions (three pillars: integrated framework; empirical characterization n≥30; cloud-anchor necessity shown by E7) → 1.7 organization.

T5.2 — Chapter 6: 6.1 findings per RQ; 6.2 contributions revisited; 6.3 limitations (E6 replay, single-site, chain archiving >100k blocks); 6.4 future work (nonce/sequence replay hardening, multi-device, archiving).

T5.3 — Front matter: title page (new title), BM+BI abstracts, TOC, list of figures/tables, abbreviations.

⛔ CHECKPOINT 5: Fable full-thesis coherence review.

PHASE 6 — Final polish

• Cross-chapter consistency pass (slot count, durations, terminology, figure/table numbering).
• Insert missing figures (roi_selector screenshot noted in Ch4 §4.4; Ch5 charts from generate_report.py — run it on the Jetson if figures are missing).
• Assemble references list in the required citation style (ask user: IEEE numeric assumed for USM engineering — confirm).
• Prepare viva slide outline (15–20 slides) — outline only; user builds slides.

⛔ FINAL CHECKPOINT: Fable review, then user sends to supervisor.

Standing rules for Sonnet

1. Never invent data, statistics, or citations. If information is missing, say so and ask.
2. The source-of-truth table above beats any conflicting number found elsewhere (except fresh CSVs from the Jetson, which beat everything — flag any conflict).
3. Stop at every ⛔ checkpoint and tell the user to switch to Fable for review.
4. Don't modify anything on the Jetson beyond running the listed experiments/scripts; never touch chain.db for the live detector.
5. Keep edits in the existing .md files in parking_system/; one commit-sized change per task so Fable can review diffs cleanly.