Enhancing Cryptographic Solutions for Resource-Constrained RFID Assistive Devices: Implementing a Resource-Efficient Field Montgomery Multiplier
Bibliographic record
Abstract
Radio Frequency Identification (RFID) assistive systems, which integrate RFID devices with IoT technologies, are vital for enhancing the independence, mobility, and safety of individuals with disabilities. These systems enable applications such as RFID navigation for blind users and RFID-enabled canes that provide real-time location data. Central to these systems are resource-constrained RFID devices that rely on RFID tags to collect and transmit data, but their limited computational capabilities make them vulnerable to cyberattacks, jeopardizing user safety and privacy. Implementing the Elliptic Curve Cryptography (ECC) algorithm is essential to mitigate these risks; however, its high computational complexity exceeds the capabilities of these devices. The fundamental operation of ECC is finite field multiplication, which is crucial for securing data. Optimizing this operation allows ECC computations to be executed without overloading the devices’ limited resources. Traditional multiplication designs are often unsuitable for such devices due to their excessive area and energy requirements. Therefore, this work tackles these challenges by proposing an efficient and compact field multiplier design optimized for the Montgomery multiplication algorithm, a widely used method in cryptographic applications. The proposed design significantly reduces both space and energy consumption while maintaining computational performance, making it well-suited for resource-constrained environments. ASIC synthesis results demonstrate substantial improvements in key metrics, including area, power consumption, Power-Delay Product (PDP), and Area-Delay Product (ADP), highlighting the multiplier’s efficiency and practicality. This innovation enables the implementation of ECC on RFID assistive devices, enhancing their security and reliability, thereby allowing individuals with disabilities to engage with assistive technologies more safely and confidently.
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame machine prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. The Gemma side is a direct model label for every work in the frame, read from the title-only record. The Codex side is a classifier learned from the 10,348 direct Codex labels and calibrated to design-weighted sample rates; fields without enough sample support carry no Codex call. Candidate is the union of the two sides; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels.
Distilled classifier scores by category (both heads)
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.000 | 0.001 |
| Meta-epidemiology (narrow) | 0.001 | 0.000 |
| Meta-epidemiology (broad) | 0.000 | 0.000 |
| Bibliometrics | 0.001 | 0.000 |
| Science and technology studies | 0.000 | 0.000 |
| Scholarly communication | 0.001 | 0.001 |
| Open science | 0.001 | 0.001 |
| Research integrity | 0.001 | 0.001 |
| Insufficient payload (model declined to judge) | 0.003 | 0.001 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one source (direct Gemma or distilled Codex), not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".