Hubbry Logo
Crypto-1Crypto-1Main
Open search
Crypto-1
Community hub
Crypto-1
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Crypto-1
Crypto-1
Crypto-1
View on Wikipedia
from Wikipedia
Crypto1
NXP Crypto1
General
DesignersPhilips/NXP
First publishedOctober 6, 2008
Cipher detail
Key sizes48 bits
Security claims48 bits
StructureNLFSR, LFSR
Best public cryptanalysis
Garcia, Flavio D.; Peter van Rossum; Roel Verdult; Ronny Wichers Schreur (2009-03-17). "Wirelessly Pickpocketing a Mifare Classic Card" claim that the cipher can be broken "in seconds".

Crypto1 is a proprietary encryption algorithm (stream cipher) and authentication protocol created by NXP Semiconductors for its MIFARE Classic RFID contactless smart cards launched in 1994. Such cards have been used in many notable systems, including Oyster card, CharlieCard and OV-chipkaart.

By 2009, cryptographic research had reverse engineered the cipher and a variety of attacks were published that effectively broke the security.[1][2][3][4][5]

NXP responded by issuing "hardened" (but still backwards compatible) cards, the MIFARE Classic EV1. However, in 2015 a new attack rendered the cards insecure,[6][7] and NXP now recommends migrating away from MIFARE Classic.[8]

See also: MIFARE § Security

Technical description

[edit]

Crypto1 is a stream cipher very similar in its structure to its successor, Hitag2. Crypto1 consists of

The usual operation of Crypto1 and Hitag2 ciphers uses nonlinear feedback only during the initialization/authentication stage, switching to operation as a LFSR with a nonlinear output filter (filter generator) for the rest of the communications.

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Crypto-1

View on Grokipedia
from Grokipedia
Crypto-1 is a developed by for use in the Classic family of contactless smart cards, providing mutual authentication and data confidentiality through a 48-bit symmetric key mechanism. It operates as a based on a single 48-bit (LFSR) with a specific primitive polynomial of degree 48, outputting one bit per clock cycle to generate a keystream for encrypting communications between the card and reader. The cipher was designed for low-power RFID applications, such as public transportation ticketing (e.g., London's , Netherlands' , and Boston's ) and systems, where Classic cards store data in 16 sectors, each protected by two 48-bit keys (A and B) that control read/write permissions. in Crypto-1 follows a challenge-response protocol: the reader sends a 32-bit nonce, the card responds with an encrypted 32-bit nonce using the shared key, and subsequent data exchanges are XORed with the keystream derived from both nonces. The implementation is highly efficient, requiring approximately 400 two-input equivalents, making it suitable for embedded hardware in passive RFID tags operating at 13.56 MHz. Despite its widespread deployment—estimated in billions of cards—Crypto-1's secrecy was compromised through reverse-engineering efforts combining physical chip analysis (via optical and delayering) and cryptanalytic protocol tracing, fully disclosing its internal structure by . Key vulnerabilities include a weak 16-bit in the protocol, enabling nested attacks, and linear weaknesses in the filter function that allow algebraic recovery of the internal state with modest computational resources (e.g., brute-force key search in under 50 minutes using FPGAs). These flaws have led to practical attacks, such as dark-side attacks exploiting unencrypted reader-card handshakes and offline key recovery via tables, rendering legacy Classic systems insecure for high-stakes applications. NXP responded by introducing hardened variants and successors like Plus and DESFire, which incorporate stronger ciphers such as AES.

Overview

Description

Crypto-1 is a proprietary and developed by for securing low-cost RFID systems. It was designed to enable between a reader and a , such as a , in applications requiring secure wireless communication. The protocol operates within resource-constrained environments, prioritizing simplicity and efficiency for embedded devices. At its core, Crypto-1 employs a 48-bit secret key to initialize its internal state. Keystream generation relies on a 48-bit linear feedback shift register (LFSR) with a nonlinear output filter, which produce pseudorandom bits through algebraic operations over GF(2). The output keystream consists of 1 bit per clock cycle, filtered nonlinearly from the register states to ensure unpredictability. This design integrates with a challenge-response mechanism, where challenges are encrypted using the generated keystream to verify authenticity. Following successful , the protocol shifts to encrypting subsequent commands and exchanges, protecting in the communication channel. It finds primary application in systems like Classic cards for and ticketing.

Applications

Crypto-1 is primarily deployed in the Classic family of RFID contactless smart cards, which were launched by Semiconductors (now ) in 1994 for applications in and micropayments. These cards utilize Crypto-1 as a to provide and in short-range communications. Notable implementations include public transportation systems such as London's , the Boston MBTA's , and the ' OV-chipkaart, as well as various systems like hotel key cards and campus identification badges. In these systems, Crypto-1 enables secure, contactless transactions by protecting data exchange between the card and reader during fare collection or entry authorization. The cipher is integrated into cards compliant with the ISO/IEC 14443 Type A standard, which supports proximity communication at 13.56 MHz with a typical read range of up to 10 cm. This standard facilitates interoperability in global RFID ecosystems, allowing MIFARE Classic cards to function in diverse reader infrastructures without proprietary modifications. Within MIFARE Classic cards, Crypto-1 secures individual memory sectors, each of which is protected by a unique 48-bit key for read and write operations, ensuring that only authorized readers can access or modify stored data such as user balances or access permissions. This sector-based protection model supports segmented data management, where different applications on the same card can use independent keys. By 2008, over 200 million MIFARE Classic cards were in active use worldwide, representing approximately 85% of the market and establishing Crypto-1 as one of the most extensively deployed RFID mechanisms. Cumulative production exceeded 3.5 billion units by the mid-2010s, underscoring its widespread adoption in transit and access systems despite subsequent security enhancements in newer card variants.

History

Development

Crypto-1 was developed in the early by Semiconductors, the predecessor to , as a core component of the product line for contactless RFID systems. Introduced alongside the MIFARE Classic series in 1994, the was designed to enable secure, affordable and data protection in resource-constrained environments. The primary motivations for Crypto-1's design centered on creating a lightweight suitable for battery-less, low-power transponders that operate via with readers. This addressed the need for mass-market applications such as ticketing and , where cost and simplicity were paramount over advanced security features, allowing implementation with approximately 400 two-input equivalents for minimal hardware footprint. The cipher was initially embedded in the microcontrollers of Classic 1K and 4K cards, which provided 1 and 4 kilobytes of memory, respectively, facilitating widespread adoption in proximity-based systems. During development, Crypto-1 was maintained as a proprietary "" algorithm, with no public specifications released to preserve its and hardware obfuscation. Key design choices, such as the 48-bit key length, prioritized cost-efficiency and hardware simplicity over higher margins, under the assumption that the physical proximity required for RFID interactions would limit practical attacks. This approach enabled low production costs, positioning cards at around 0.5 euros each, far below alternatives employing stronger ciphers like .

Publication and Disclosure

The Crypto-1 , integral to the Classic contactless smart cards, was developed by Semiconductors (now ) and maintained under proprietary secrecy since the cards' introduction in 1994, with no independent cryptographic review during this 14-year period. This approach relied on security by obscurity, a practice that became central to subsequent debates following the cipher's exposure. The full algorithm was first publicly disclosed through the presentation of the paper "Dismantling MIFARE Classic" at the 13th European Symposium on Research in (ESORICS 2008) in Malaga, , by a team of researchers from Radboud University's Digital Security Group in the , including Flavio D. Garcia and Roel Verdult. The team achieved this by reverse-engineering the via side-channel attacks on exposed MIFARE Classic chips, extracting its complete structure after months of analysis starting in 2007. Prior to publication, NXP sought to suppress the research through legal action, filing for a in a Dutch district on July 10, 2008, against Radboud University and its dean Bart Jacobs to prevent release of the details; the denied the on July 18, 2008, citing freedom of scientific expression and ruling that the potential harm did not outweigh . This ruling intensified discussions on the risks of and the value of open security analysis. In the aftermath, NXP faced mounting pressure from the research community and affected systems worldwide, leading to the of a partial for the MIFARE Classic in , which detailed the card's protocol and but omitted full internals of the Crypto-1 , now publicly known. This marked a partial shift from complete secrecy to limited transparency, though the company continued to emphasize migration to more secure alternatives amid ongoing vulnerabilities. The events underscored a broader transition in RFID security from closed to scrutinized designs, influencing industry practices for proprietary algorithms.

Technical Description

Architecture

Crypto-1 features a hybrid design centered on a 48-bit linear feedback shift register (LFSR) that maintains the internal state, combined with a nonlinear filter function to generate the keystream and introduce essential nonlinearity. The LFSR operates with a primitive generating polynomial of degree 48, defined as x48+x43+x39+x38+x36+x34+x33+x31+x29+x24+x23+x21+x19+x13+x9+x7+x6+x5+1x^{48} + x^{43} + x^{39} + x^{38} + x^{36} + x^{34} + x^{33} + x^{31} + x^{29} + x^{24} + x^{23} + x^{21} + x^{19} + x^{13} + x^{9} + x^{7} + x^{6} + x^{5} + 1, featuring taps at bits 0, 5, 6, 7, 9, 13, 19, 21, 23, 24, 29, 31, 33, 34, 36, 38, 39, and 43 (0-indexed from the least significant bit). This configuration ensures a maximum period of 248−12^{48} - 1, providing a long sequence before repetition. The LFSR advances synchronously on each clock cycle at approximately 106 kHz, shifting the state bits toward the output end while computing the new input bit as the XOR of the tapped positions to maintain in the state evolution. The then processes subsets of the 48-bit state to produce one keystream bit per cycle, using nonlinear functions applied to selected groups of four state bits, consisting of five such functions producing intermediate bits that are combined by a further nonlinear function to yield a output that resists linear approximations and attacks. This filter ensures the overall keystream is nonlinear despite the linear state update. In operation, the full 48-bit LFSR state serves as the core component, clocked uniformly to evolve the without asynchronous elements. For , the reader and card derive a shared from a 48-bit master key, initializing the LFSR with concatenated key and challenge values (including the card's unique ID) in a mutual challenge-response protocol compliant with ISO 9798-2, where the generates encrypted responses to verify legitimacy.

Key Schedule and Initialization

In Crypto-1, key diversification generates a unique 48-bit sector key from a 48-bit master key through a that incorporates the card's 4-byte (UID) to ensure per-card uniqueness and mitigate risks from key sharing across devices. This approach binds the derived keys to the hardware-specific UID, making it difficult for cloned cards without the original UID to authenticate successfully. The process follows a three-pass challenge-response protocol compliant with ISO 9798-2, establishing a shared session for . The reader begins by transmitting an authentication command that specifies the target sector and the key type (A or B, both 48-bit). The card generates and sends a 32-bit nonce (denoted as NtN_t) in response, which serves as the initial challenge. The reader then encrypts and transmits its own 32-bit nonce (NrN_r) along with a of the card's nonce, using the emerging session keystream; the card verifies this and replies with an encrypted of the reader's nonce to complete . This exchange ensures both parties possess the correct sector key without directly transmitting it. Initialization of the cipher state uses the 32-bit card nonce as an (IV), combined with the sector key to set the internal registers. The 48-bit key is loaded into the LFSR according to a fixed bit (e.g., key bit 0 to LFSR position 47, and subsequent bits to other fixed locations). The initial state for the session is obtained by clocking the LFSR 32 times while shifting in the 32-bit card nonce bits sequentially; a similar process incorporates the reader's after verification to synchronize the states. The component draws from this LFSR state for output generation. Reverse-engineering has revealed the specific bit used in this loading to prepare the starting state. The LFSR and states are thus loaded in tandem to prepare for keystream production. Session key generation produces a temporary keystream from the initialized registers, clocked forward to encrypt subsequent messages via bitwise XOR. This keystream evolves with each by incorporating fresh nonces, ensuring uniqueness per session and resistance to replay attacks through nonce non-repetition. The process binds the session to the specific authentication exchange, limiting exposure if intercepted.

Stream Generation

The stream generation in Crypto-1 relies on a 48-bit linear feedback shift register (LFSR) whose state is updated each clock cycle to produce the internal sequence, with a nonlinear filter applied to generate the output keystream bits. The LFSR advances by shifting its contents one position to the left, replacing the least significant bit with a feedback bit computed as the parity (XOR) of specific state bits defined by the primitive feedback polynomial g(x)=x48+x43+x39+x38+x36+x34+x33+x31+x29+x24+x23+x21+x19+x13+x9+x7+x6+x5+1g(x) = x^{48} + x^{43} + x^{39} + x^{38} + x^{36} + x^{34} + x^{33} + x^{31} + x^{29} + x^{24} + x^{23} + x^{21} + x^{19} + x^{13} + x^9 + x^7 + x^6 + x^5 + 1. This polynomial ensures a maximum period of 248−12^{48} - 1 states, providing a long pseudorandom sequence from the initial key-derived state. The keystream bit zkz_k at each step kk is produced by a two-layer nonlinear filter function ff applied to 20 selected bits from the current LFSR state, specifically at odd positions starting from bit 9: zk=f(rk+9,rk+11,rk+13,…,rk+47)z_k = f(r_{k+9}, r_{k+11}, r_{k+13}, \dots, r_{k+47}), where rr denotes the LFSR bits. The first layer consists of five functions on disjoint 4-bit subsets of these 20 bits—two using the truth table encoded as 0x26c70x26c7 and three using 0x0dd30x0dd3—yielding five intermediate bits. These five bits then feed into a second-layer nonlinear function with truth table 0x4457c3b30x4457c3b3, producing the final keystream bit zkz_k. This structure introduces nonlinearity to decorrelate the linear LFSR output from the keystream, aiming to enhance . In encryption mode, the generated keystream is XORed bit-by-bit with data, such as commands or read/write payloads, typically processed in 8-byte blocks to maintain protocol compatibility. The tag and reader synchronize their LFSR states during , ensuring matching keystreams for confidentiality in subsequent operations. Theoretically, Crypto-1 generates one keystream bit per clock cycle of the LFSR, but practical throughput is constrained by the underlying ISO/IEC 14443 RFID protocol's data rate of approximately 106 kbps.

Cryptanalysis

Initial Breaks

The initial major cryptanalytic breaks of Crypto-1 occurred in , led by researchers from the Digital Security group at , including Flavio D. Garcia and Peter van Rossum. These attacks exploited weaknesses in the and the stream cipher's structure, combining protocol manipulations with offline computations to recover the full 48-bit keys. The methods relied on or interacting with the card during to obtain traces, followed by efficient key recovery algorithms that revealed the cipher's internal state. One key approach was the nested attack, which used repeated authentication sessions to induce protocol "faults" by interrupting or timing out communications, allowing recovery of partial keystreams from the nonlinear feedback (NLFSR) component. This was combined with targeting the (LFSR), where approximations of the filter function enabled reconstruction of the LFSR state from observed bits. By correlating outputs from both registers, the full internal state could be recovered offline in under a minute on standard hardware, with the attack requiring only a few authentication traces obtained via side-channel means such as electromagnetic emissions or power consumption leaks during card-reader interactions. The full disclosure came in the publication "Dismantling MIFARE Classic" by Garcia et al., detailing two complementary attacks: the nested method, which involved precomputing tables for partial states (taking 4-8 hours once) and recovering keys in about 2 minutes using roughly 4096 sessions, and a pure linear attack that avoided precomputation, cracking keys in under 40 milliseconds with tables of about 2^19 entries each. The overall complexity for key search was approximately 2^20 operations, exploiting correlations between the linear and nonlinear parts of the cipher. These techniques allowed complete key recovery without physical tampering, using only wireless interactions. Practically, the attacks enabled cloning of MIFARE Classic cards using inexpensive equipment, such as a Proxmark3 reader costing around $200, by on legitimate authentications and performing offline analysis. This was demonstrated live at the 25th (25C3) in December 2008, where researchers showed real-time card cloning, highlighting vulnerabilities in widespread applications like ticketing and . The breaks underscored Crypto-1's insecurity, as even brief proximity to a card during use sufficed for compromise.

Subsequent Attacks

Following the initial breaks of Crypto-1 in 2008–2009, researchers developed attacks targeting patched and hardened variants of Classic cards, which incorporated mitigations such as diversified nonces and removal of exploitable parity bits. In , Ding et al. presented a card-only attack on patched Classic implementations, such as the 2.0, using a combination of algebraic and differential techniques. The attack derives equations from observed keystream bits during authentication attempts and solves them using SAT solvers and algorithms, recovering the 48-bit key despite the use of random, unpredictable nonces. Computation time ranged from 2 to 15 minutes on a standard PC after collecting 10–20 hours of traces via repeated interactions, demonstrating practicality against implementations that fixed earlier nonce predictability issues. In 2015, and Verdult extended ciphertext-only to hardened Classic variants, including the EV1 revision, which eliminated known implementation flaws like leaked error codes and parity bits. Their approach exploits structural weaknesses in the Crypto-1 filter function through algebraic techniques and differential analysis, reducing the effective key search space from 2^{48} to approximately 2^{30} operations when one sector key is known (often obtainable via default keys or ). The attack requires only wireless on legitimate authentications and achieves full key recovery in about 5 minutes on a single-core consumer , confirming the persistence of core vulnerabilities even in updated hardware. Subsequent computational advances further accelerated key recovery for standard MIFARE Classic cards. Between 2010 and 2012, optimizations to nested attacks—building on the foundational 2009 method—leveraged parallel processing to reduce offline computation times from minutes to seconds in favorable cases, enabling faster exploitation of nonce correlations during multi-sector authentications. By , Tezcan demonstrated a GPU-accelerated exploiting leaked parity bits in non-hardened cards, achieving key recovery in under 5 hours on a single GTX 970 GPU; for hardened variants lacking such leaks, the time extended to about 7 hours when assuming partial key knowledge. These improvements highlight how scaled existing cryptanalytic primitives, making attacks viable on commodity hardware. In 2024, Philippe Teuwen disclosed new vulnerabilities in the FM11RF08S chip, a Classic-compatible variant using Crypto-1, including a that compromises all user-defined keys and a static encrypted nonce issue. The backdoor attack requires physical access to the card for a few minutes and allows full key recovery without prior knowledge, affecting variants like 0590 and 0598. Optimizations to nested attacks using the backdoor reduce recovery time by a factor of six. This finding, as of August 2024, underscores ongoing risks in legacy and compatible implementations.

Legacy and Replacements

Security Statements

In response to the 2008 cryptanalysis revealing vulnerabilities in Crypto-1, NXP Semiconductors opposed the publication of the research, arguing it would enable criminal exploitation of security systems. A Dutch court ruled in favor of the researchers at Radboud University, permitting publication on grounds of freedom of speech and noting that any damage stemmed from the chip's design flaws rather than disclosure. Attacks published in 2015, including ciphertext-only on hardened Classic EV1 cards, demonstrated persistent weaknesses in Crypto-1 despite hardware updates. Further vulnerabilities were exposed in August 2024 through analysis of a static encrypted nonce variant in Classic cards, allowing efficient key recovery. NXP positions Crypto-1-based cards as suitable only for low-risk legacy applications and recommends migration to AES-based alternatives like DESFire for modern deployments. As of 2025, NXP's product literature emphasizes deprecation of Crypto-1 for new designs due to demonstrated breaks enabling unauthorized access.

Migration Recommendations

NXP Semiconductors recommends transitioning away from the vulnerable Crypto-1 algorithm in Classic cards to more robust alternatives, primarily DESFire and Plus variants, which incorporate AES-128 or 3DES for , , and secure messaging. These solutions support seamless upgrades in existing infrastructures, such as public transit and , by maintaining in initial security levels while enabling a shift to higher protection through over-the-air updates or sector-wise migrations. DESFire, in particular, offers multi-application flexibility and EAL5+ certification, making it suitable for diverse deployments requiring long-term security. Instead, MIFARE Plus serves as a practical bridge, allowing operation in a Classic-compatible mode initially before upgrading to AES-128, with features like transaction-oriented anti-tear protection to prevent during concurrent reads. Key best practices for migration emphasize robust reader-side to diversify session keys across devices, preventing widespread compromise from single key leaks, alongside mandatory protocols using longer, unpredictable nonces to thwart replay and nesting attacks. System operators are advised to phase out legacy Crypto-1 cards progressively, aligning with broader timelines for quantum-resistant cryptography in critical infrastructures by 2030, as outlined in strategies. In the , regulatory pressures under GDPR further accelerate this shift by mandating enhanced data protection and privacy in RFID systems, promoting alternatives that support secure data transmission and minimize unauthorized tracking risks. For IoT applications, NXP's NTAG series provides a lightweight, cost-effective option with AES-128 support and compatibility with NFC Forum standards, facilitating integration in low-security scenarios like while encouraging upgrades from insecure deployments. Significant challenges arise in large-scale implementations, particularly public transit networks where millions of legacy cards are in circulation, requiring dual-mode readers and gradual card replacements to maintain service continuity without disrupting daily operations for billions of users.

References

  1. https://www.usenix.org/event/sec08/tech/full_papers/nohl/nohl_html/
  2. https://eprint.iacr.org/2008/166.pdf
  3. https://www.midnightblue.nl/research/cryptanalysis-of-hardened-mifare-classic-cards
  4. https://www.usenix.org/legacy/event/sec08/tech/full_papers/nohl/nohl.pdf
  5. https://arxiv.org/pdf/0803.2285
  6. https://www.sciencedirect.com/science/article/abs/pii/S1363412710000348
  7. https://www.nxp.com/products/rfid-nfc/mifare-hf/mifare-classic:MC_41863
  8. https://www.researchgate.net/publication/220334848_Algebraic_Attacks_on_the_Crypto-1_Stream_Cipher_in_MiFare_Classic_and_Oyster_Cards
  9. https://www.nxp.com/docs/en/data-sheet/MF1S50YYX_V1.pdf
  10. https://www.cs.ru.nl/~rverdult/Security_Flaw_in_MIFARE_Classic-2008.pdf
  11. https://pdfs.semanticscholar.org/bb0c/525225aaae0819abea5ae2dc22ef6aceb174.pdf
  12. https://blackhat.com/docs/sp-14/materials/arsenal/sp-14-Almeida-Hacking-MIFARE-Classic-Cards-Slides.pdf
  13. https://www.nxp.com/company/about-nxp/smarter-world-blog/BL-25-YEARS-OF-MIFARE
  14. https://flaviodgarcia.com/publications/Tiny.Star.pdf
  15. https://link.springer.com/chapter/10.1007/978-3-540-88313-5_7
  16. https://www.sos.cs.ru.nl/applications/rfid/main.html
  17. https://www.usenix.org/event/sec08/tech/full_papers/nohl/nohl.pdf
  18. https://pdfs.semanticscholar.org/1e28/293652f130b61824696dbe65a0c7b85053c1.pdf
  19. https://www.researchgate.net/figure/Keystream-generation-of-CRYPTO-1-1_fig1_331162004
  20. https://www.nxp.com/docs/en/application-note/AN10922.pdf
  21. https://link.springer.com/content/pdf/10.1007/978-3-540-85893-5_20.pdf
  22. https://hitcon.org/download/2010/11_MIFARE%20Classic%20IS%20Completely%20Broken.pdf
  23. https://doi.org/10.1007/978-3-540-88313-5_7
  24. https://arxiv.org/abs/0803.2285
  25. https://link.springer.com/chapter/10.1007/978-3-319-12087-4_10
  26. http://cs.ru.nl/~rverdult/Ciphertext-only_Cryptanalysis_on_Hardened_Mifare_Classic_Cards-CCS_2015.pdf
  27. https://www.scitepress.org/papers/2017/62627/62627.pdf
  28. https://eprint.iacr.org/2024/1275
  29. https://www.reuters.com/article/dutch-hacking/dutch-courts-oks-publishing-how-to-hack-nxp-chip-idUSL186504120080718/
  30. https://eprint.iacr.org/2024/1275.pdf
  31. https://www.nxp.com/docs/en/fact-sheet/MIFARE-PLUS-SE-FS.pdf
  32. https://www.nxp.com/products/rfid-nfc/mifare-hf/mifare-desfire:MC_53450
  33. https://www.nxp.com/products/MIFARE_PLUS_SE_1K
  34. https://www.nxp.com/products/MFPEV2
  35. https://www.nxp.com/docs/en/data-sheet/MF3D_H_X3_SDS.pdf
  36. https://www.nxp.com/docs/en/data-sheet/MF1P%28H%29x2.pdf
  37. https://www.nxp.com/products/rfid-nfc/mifare-hf/mifare-plus:MC_57609
  38. https://www.nxp.com/docs/en/data-sheet/MF0AES%28H%2920.pdf
  39. https://industrialcyber.co/regulation-standards-and-compliance/eu-begins-coordinated-effort-for-member-states-to-switch-critical-infrastructure-to-quantum-resistant-encryption-by-2030/
  40. https://www.nedap-retail.com/impact-of-the-new-eu-privacy-regulation-on-rfid-implementations-in-retail-stores/
  41. https://www.nxp.com/products/wireless-connectivity/nfc-hf/ntag-for-tags-and-labels:NTAG-TAGS-AND-LABELS
  42. https://www.rfidlabel.com/nxp-ntag-nfc-label-iot/
  43. https://www.idemia.com/citygo-mifare-transport-product-range
  44. https://documents1.worldbank.org/curated/en/564001469009916441/pdf/107014-WP-P148489-PUBLIC-Phase-2-Public-Transport-AFC-Interoperability-Final-Report-June-10-2016.pdf
Add your contribution
Related Hubs
User Avatar
No comments yet.