PaperlayerView exact revision on arXiv

Source-linked AI summary

Bringing Hardware Security Education to All: A Seamless Curriculum Integration Approach

Tanvir Hossain, Mahmudul Hasan, Kareem El-Araby, Lorenzo R. Godinez, Swarup Bhunia, Md Tauhidur Rahman, Tamzidul Hoque

arXiv:2610.36219v1cs.CRcs.CY

TL;DR

Undergraduate curricula often overlook hardware security, while dedicated courses are scarce, costly, and reach few students. The paper integrates hands-on security modules into existing core courses by using security concepts to exercise course design concepts. Its reported evidence is bounded by small, uneven, self-reported survey samples and the absence of a comparison group.

  • Problem

    Dedicated hardware security courses reach few undergraduates and require resources that can be impractical for institutions, while core courses remain a potential route to students.

    Source: §I · pp. 1–2

  • Method

    The paper integrates nine hands-on hardware security modules into existing courses, using security concepts to exercise design concepts and reusing course instruments.

    Source: C. Design Principles · p. 3, §VIII · p. 10

  • Results

    Instructors’ setting around a module, including its status in the grade book and whether it ends in a repair, shaped what students reported receiving from it.

    Source: §VI · p. 9

  • Takeaways & Limitations

    Core-course integration offers a way to deliver hardware security education through existing courses rather than a separate offering.

    Source: §I · p. 2

    The cohorts were not randomized, no section ran without modules, and small uneven samples and self-reported ratings limit claims about learning gains.

    Source: §VII · p. 9

Abstract

from arXiv · show

Cybersecurity education has predominantly focused on software and network security, under the assumption that the underlying hardware is trustworthy. Threats introduced through the global semiconductor supply chain, together with vulnerabilities arising during design and integration, challenge the assumption that hardware can serve as an unquestioned root of trust. Sensor-enabled systems and machine-learning accelerators further expand the hardware attack surface. The undergraduate curriculum of electrical and computer engineering and computer science programs has not evolved accordingly. Core courses cover the design and the functionality of hardware while the security aspects remain overlooked, and dedicated hardware security (HS) courses are elective, scarce, and often restricted to graduate students. At the University of Florida, fewer than 7% of the undergraduate electrical and computer engineering students register for the introductory HS course each year. We present an integrated and economical approach that disseminates fundamental HS concepts within existing core courses through contextual learning. Nine hands-on modules were developed such that each security concept exercises an associated design concept of the core course, as a component of that course and not as a course of their own. Doing the security work is how the student exercises the design topic, so the modules are built to strengthen the host course and not only to add to it. Three were assessed across three offerings of the embedded systems course through one course survey and two conducted by an external evaluator, with 25 respondents. We report what those instruments measured and the limitations of the approach.

I. INTRODUCTION

Hardware security remains largely absent from undergraduate curricula even as supply-chain and implementation threats make hardware a target. The paper proposes integrating hands-on security modules into existing core courses so that security work exercises the design concepts those courses teach.

I. INTRODUCTION

  • Hardware security is overlooked in core ECE and CS courses, while software- and network-focused cybersecurity courses leave hardware security expertise unaddressed.Hardware supply-chain threats include piracy, reverse engineering, cloning, and malicious modification.Source: §I · p. 1
  • Dedicated hardware security courses face limited reach, high resource demands, and fragmented instruction that separates attacks from the design choices permitting them.At the University of Florida, fewer than 7% of ECE undergraduates register for the introductory course each year.Source: §I · pp. 1–2
  • The proposed contextual approach makes a security concept the means by which students exercise a core course’s design concept, rather than adding a separate topic.The security and design aspects are learned together to strengthen the host course’s learning outcome.Source: §I · p. 2
  • The paper develops nine hands-on modules across three core courses, assesses three across three course offerings, and reports lessons for adopting institutions.The assessment includes survey data from 25 respondents, collected in part by an external evaluator.Source: §I · p. 2

II. BACKGROUND AND RELATED WORK

Existing routes into hardware security include dedicated-course materials, competitions, and hardware-fundamentals activities, but the paper identifies a gap in reaching students before they choose the field. Its contextual framework selects security concepts for the design concepts they let students practice.

II. BACKGROUND AND RELATED WORK

  • Hardware security education reaches students through dedicated-course materials, competitions, and hardware-fundamentals activities, but the latter do not directly integrate security content.Examples include a hands-on textbook, remote laboratory, contests, configurable platforms, and board games.Source: §II · p. 2
  • Dedicated courses and competitions primarily reach students already interested in hardware security, leaving a need for a route that reaches students before they choose the field.The paper says no prior work reports a module suite meeting its three conditions: design-concept reinforcement, paired defense where possible, and repeated survey assessment including independent evaluation.Source: §II · p. 2

III. THE CONTEXTUAL LEARNING FRAMEWORK

  • The framework places a security concept in a core design course when it gives students a reason to use a design concept that course already teaches.Source: §III · p. 2

A. Advantages of Integration

The paper argues that integrating hardware security into core courses can broaden access, connect attacks to design, and avoid creating a separate course. It selects concepts that exercise existing course content and sets rules for module design and coverage.

A. Advantages of Integration

  • Integration can reach all students taking core design courses, provide an unfragmented view of security, avoid the cost of a new course, and extend to other topics such as AI and IoT.Source: A. Advantages of Integration · p. 2

M2 Buffer overflow

  • A buffer overflow makes stack-frame bookkeeping consequential: students see how overrunning a buffer changes the saved return address.The example links the calling convention and memory map to a design choice students can observe.Source: B. The Selection Principle · p. 3

B. The Selection Principle

  • Fault injection on a cryptographic core is excluded from a first embedded systems course because it requires equipment and subject matter that course does not teach.Source: B. The Selection Principle · p. 3

C. Design Principles

  • Modules must exercise a syllabus concept, reuse course instruments, and align with the week that concept is taught.The module suite also separates acquisition from analysis when lab time is insufficient.Source: C. Design Principles · p. 3
  • A module should include a defense where its target permits one; M1 is reported as closing without a defense.The suite’s coverage model spans supply-chain and field threats, with memory safety outside that split.Source: C. Design Principles · p. 3, Figure 2 · p. 3

D. Coverage Model

The nine-module suite spans five security concepts and is organized around the design topics each module exercises. Delivery is designed to fit existing course structures, with a limited number of modules and modest added lecture time.

D. Coverage Model

  • The nine modules cover five security concepts, including field threats, supply-chain threats, and memory safety; the catalog offers instructors options suited to course structure, student background, and teaching capacity.The four stage-classified concepts are reverse engineering, side-channel analysis, design obfuscation, and hardware Trojan insertion; the paper claims no coverage beyond the concepts shown in its coverage figure.Source: D. Coverage Model · p. 3

E. Integration Cost

  • Each module adds about 30–40 minutes of lecture, with no more than about two additional lecture hours per semester and a cap of three modules.The remaining adjustment reuses existing laboratory and assignment slots.Source: E. Integration Cost · p. 4

IV. MODULE DESIGN

  • Each of the nine modules is placed in the week its host course covers the design concept it exercises, and modules range from delivered with survey data to written material only.M1–M3 were delivered in embedded systems with survey data; M9 was delivered in computer architecture without a survey, while M4 and M6–M8 exist as written laboratory material.Source: §IV · p. 4

A. M1: Binary Reverse Engineering

M1 has students reconstruct an embedded program from its binary, while M2 demonstrates how an overflow can expose protected data and asks students to repair the vulnerability. The modules connect low-level program behavior with security consequences.

A. M1: Binary Reverse Engineering

  • M1 has students recover sensor-sampling behavior, stored values, a threshold, and an output port from an undocumented binary, then explain how changing a conditional jump to a function call affects execution.The exercise traces instructions, registers, memory, arithmetic, and control flow; M1 closes with no defense.Source: A. M1: Binary Reverse Engineering · p. 4

B. M2: Buffer Overflow

  • On an Intel 8051, students use overlength inputs to exploit an unsafe copy into a fixed-size buffer, redirect execution to an existing data-return sequence, recover protected values, then prevent out-of-bounds writes and justify the fix.The lecture names stack canaries and ASLR, while the repair must work on a bare-metal 8-bit target.Source: B. M2: Buffer Overflow · p. 4

C. M3: Timing Side Channel

M3 teaches timing leakage in password verification and has students test a constant-time repair with the same measurement instrument. M4 uses an undocumented board to practice reconstruction, producing artifacts associated with a cloner’s initial work.

C. M3: Timing Side Channel

  • M3’s early-exit password check has input-dependent execution time, and students compare vulnerable and constant-time versions using debugger timing measurements.The lecture materials show eight demonstration guesses taking 122–291 machine cycles; students measure five guesses in the laboratory.Source: C. M3: Timing Side Channel · pp. 4–5
  • Students produce timing tables for both M3 implementations to evaluate the defense; it is the only module that experimentally measures its defense with the attack’s instrumentation.The module teaches how execution-time variation can reveal information about a secret password and how constant-time comparison can remove that dependence.Source: C. M3: Timing Side Channel · pp. 4–5

D. M4: Board Reverse Engineering

  • M4 has students reconstruct an undocumented board into a bill of materials, block diagram, and functional hypothesis—the first artifact a cloner produces.The laboratory material specifies no defensive deliverable.Source: D. M4: Board Reverse Engineering · p. 5

E. M5: Power Side Channel

M5 uses switching-current transients to narrow an unknown logic gate to two candidates. M6 teaches key-controlled adder locking, and M7 applies a rare-trigger Trojan to that locked design.

E. M5: Power Side Channel

  • M5 uses a sense resistor to make switching current visible as voltage; because the transient shows an output transition but not its direction, a gate and its complement remain indistinguishable.Students infer the gate function from a transition table built across six ordered input transitions.Source: E. M5: Power Side Channel · pp. 5–6

F. M6: Combinational Logic Locking of a Ripple Carry Adder

  • M6 locks a 4-bit ripple-carry adder with a 3-bit key; the correct key yields binary addition for all 256 input combinations, while incorrect keys corrupt the carry chain.The XOR/XNOR and multiplexer styles corrupt carries differently, with the error propagating to higher bits.Source: F. M6: Combinational Logic Locking of… · p. 6

G. M7: Hardware Trojan Insertion

  • M7 adds a rare input trigger and key-altering payload to the locked adder, which adds correctly except at the trigger combination, where the altered key corrupts the carry chain and sum.The fault propagates across higher bits, while other input combinations leave the Trojan hidden.Source: G. M7: Hardware Trojan Insertion · p. 6

H. M8: Sequential Logic Locking of a UART Transmitter

M8 uses sequential key states to lock a UART transmitter, while M9 turns cache timing into a channel for observing another process. The Fall 2024 knowledge figure reports students’ self-ratings before and after the course.

H. M8: Sequential Logic Locking of a UART Transmitter

  • Incorrect key values send the UART state machine into a LOCKED state that holds the transmit line high until reset.The reference key is AA, BB, CC, supplied one value per clock; the correct sequence returns the transmitter to IDLE.Source: H. M8: Sequential Logic Locking of a… · p. 6
  • M8 contrasts a key distributed over several clock cycles with a single combinational key and explains the LOCKED state as a blackhole.The procedure tests the correct key sequence and wrong values at each of its three positions.Source: H. M8: Sequential Logic Locking of a… · p. 6

I. M9: Cache Side Channel

  • Fall 2024 Figure 5 reports self-rated knowledge before and after the course on a four-point scale, from no knowledge to strong knowledge.The module aim is to show that the cache hierarchy taught in the course can also act as an information channel.Source: §I · p. 6, Figure 5 · p. 7
  • Across 90 probes, cache hits measured 96–104 cycles and misses 144–168 cycles, separated by a 40-cycle gap around a 110-cycle threshold.The lecture uses the timing series to read the victim’s access pattern; prime and probe is presented when memory is not shared.Source: §I · pp. 6–7

V. DEPLOYMENT AND SURVEY RESULTS

The paper reports deployment of hardware-security modules within existing courses and survey evidence from three offerings. The external evaluation found positive hands-on and learning responses, while the instruments and small cohorts constrain interpretation.

A. What Was Deployed

  • The modules remained components of existing courses, pairing lecture segments and homework with topics already on those courses’ syllabi.The reported deployments were in embedded systems and computer architecture; no more than three modules ran in a semester.Source: A. What Was Deployed · p. 7

B. Surveys and the External Evaluation

  • The evidence combines an internal Spring 2023 survey with external end-of-course surveys in Spring and Fall 2024.The 2023 survey received 13 responses; the Spring 2024 survey received 8 of 13 students, and the Fall 2024 report records 4 responses.Source: B. Surveys and the External Evaluation · p. 7
  • Most Spring 2024 respondents said the modules helped their understanding of embedded-systems fundamentals, and both 2024 cohorts reported more hands-on learning than in comparable courses.The external evaluator’s reports also noted increased Fall interest in hardware security and instructional support, lecture coverage, and study materials as areas to strengthen.Source: B. Surveys and the External Evaluation · p. 8
  • The instruments differed across offerings, and the authors neither pooled cohorts nor applied significance tests because samples were small.The Spring 2024 cohort had 8 responses and the Fall 2024 report records 4; the reports do not identify the institution of each offering.Source: B. Surveys and the External Evaluation · pp. 7–8, Table II · p. 8

C. Per-Module Ratings

The section reports below-midpoint usefulness ratings in Spring 2023, increased self-reported knowledge in Fall 2024, and differing outcomes across the two 2024 cohorts. Hands-on exposure was reported by both cohorts, while fundamentals and downstream outcomes varied.

C. Per-Module Ratings

  • The Spring 2023 module usefulness means ranged from 2.36 to 2.83, all below the five-point scale midpoint of 3.00.The lowest mean, 2.36, was for M2’s contribution to prior understanding of memory layout; several students said they had not attempted the bonus assignment.Source: C. Per-Module Ratings · p. 8

D. Knowledge and Interest

  • Fall 2024 self-reported knowledge rose from 1.3 to 2.5 for binary reverse engineering, 1.8 to 2.5 for buffer overflow, and 1.0 to 2.0 for side-channel attacks.Fall interest in hardware security rose from 2.8 to 4.5; Spring 2024 reported end-of-course interest of 9.1 and overall experience of 7.6 on the ten-point scale.Source: D. Knowledge and Interest · p. 8

E. Student Outcomes

  • 87% of Spring 2024 respondents and 25% of Fall 2024 respondents said the modules helped with embedded-systems fundamentals.Half of Fall respondents said they did not attempt the assignments, and half identified teaching-assistant support as their greatest improvement need.Source: E. Student Outcomes · p. 8
  • Spring 2024 respondents reported stronger downstream outcomes than Fall respondents, including HS internship searches by every Spring respondent.In Spring, 75% reported changed graduate-degree interest and 50% wanted an HS career; no Fall respondent reported changed graduate-degree interest.Source: E. Student Outcomes · p. 8

F. Barriers to Completion

Reported completion barriers were instructional, with different leading options across cohorts. The discussion connects module uptake to instructional support, assignment status, and the presence of a student-built repair.

F. Barriers to Completion

  • In Spring 2023, worked examples and lecture coverage accounted for 62.5% of M1 and 61.9% of M2 barrier selections; Fall 2024 respondents named teaching-assistant support most often at 50%.Fall respondents also selected lecture coverage, study materials, and time at 25% each; Spring 2024 was not asked this item.Source: F. Barriers to Completion · p. 8, Table IV · p. 9

G. Sources of the Reported Data

  • The reported values come from course, evaluation, lecture, and laboratory records, and fields left blank in a source are marked unreported.For example, barrier shares for Spring 2023 derive from the survey export, while the 2024 barrier shares derive from evaluation reports.Source: G. Sources of the Reported Data · p. 9

VI. DISCUSSION

  • The discussion links student experience to module setting: a repair-producing module drew strong free responses, while optional bonus status led one student to skip material later examined.The revised overflow handout added a partial-credit ladder and procedural hints; these changes cost less than a dedicated course.Source: §VI · p. 9

VII. LIMITATIONS

The study’s evidence is bounded by small, uneven self-report samples and limited student testing. The conclusion presents the nine-module integration approach and its reported outcomes, while noting work still needed to extend and test the suite.

VII. LIMITATIONS

  • The cohorts were not randomized, there was no comparison group, and self-reported knowledge ratings were not validated or isolated from other course activities.No instrument separated module contributions from the course’s examinations, projects, and grading.Source: §VII · p. 9
  • The three cohorts returned 13, 8, and 4 responses, and the instrument changed between the 2024 offerings, leaving several items represented in only one cohort.Only Spring 2024 had a known response rate, at 62%; the closed barrier item omitted an equipment option.Source: §VII · p. 9
  • The three embedded-systems modules share one 8-bit target, and whether their concepts carry to a 32-bit core is untested.The vendor environment used for the target does not run on every student platform.Source: §VII · pp. 9–10

VIII. CONCLUSION

  • The study developed nine hands-on modules spanning embedded systems, digital logic design, and computer architecture; in two cohorts, 87% and 100% of respondents reported more hands-on learning than in other courses.In the cohort with matched ratings, self-reported knowledge rose by 0.7 to 1.2 points on a four-point scale; the external evaluation recorded increased interest in graduate study and HS internships.Source: §VIII · p. 10
  • The authors plan to extend the suite to concepts it does not yet reach and test whether the selection principle carries to a 32-bit target.The conclusion frames the approach as a delivery route that does not depend on students electing hardware security.Source: §VIII · p. 10
Loading 2610.36219v1…