Open design keyless entry

Open design keyless entry refers to designing and building a keyless entry or access control system using open source hardware, open source software, publicly documented protocols, and replaceable components. The goal is to create an entry system that can be studied, modified, repaired, audited, reproduced, and improved without depending entirely on one proprietary manufacturer.

An open design keyless entry system could be used for homes, workshops, offices, makerspaces, laboratories, storage areas, vehicles, cabinets, or other controlled spaces. Depending on the design, access could be granted through RFID, NFC, a keypad, a smartphone, a cryptographic token, biometrics, or combinations of several methods.

The project can be approached as a learning platform involving electronics, software development, cybersecurity, mechanical design, networking, privacy, and open source hardware. It can also be used to study an important engineering problem: how to make convenient access control without creating unnecessary dependence on cloud services, proprietary software, or hardware that becomes unusable when a manufacturer stops supporting it.

What makes the design open?

An open keyless entry project can include several forms of source material.

Circuit schematics. PCB design files. Enclosure designs. Mechanical drawings. Firmware source code. Server software. Mobile or web interface source code. Communication protocols. Database structure. API documentation.

Bills of materials. Assembly instructions. Configuration files. Test procedures. Security documentation. Installation instructions. Maintenance procedures. Version history. Known limitations. Open licenses.

Providing editable source files is particularly important. Publishing a photograph or wiring diagram can help another person understand a project, but editable PCB, CAD, firmware, and software files make it substantially easier for people to reproduce or improve the system.

Basic system architecture

A keyless entry system normally needs several basic components.

The credential represents the person or device requesting access. This might be an NFC card, phone, keypad code, hardware token, or another authentication method.

The reader receives the credential.

The controller decides whether the credential is authorized.

The locking hardware physically controls the door or other barrier.

The system may also include a database, networking hardware, sensors, logging, management software, and backup power.

A simplified architecture could be:

credential → reader → controller → authorization decision → lock

An open design can keep these components modular so that one component can be replaced without redesigning the entire system.

Authentication methods

Several authentication methods could be supported.

RFID and NFC

RFID and NFC cards or tags can provide convenient contactless access.

A user presents a credential to a reader and the controller determines whether access should be granted.

Simple systems may identify cards using static identifiers. More security-focused systems can use credentials capable of stronger cryptographic authentication.

Open projects should clearly document which credential technologies they support and what security assumptions those technologies make.

Keypad

A keypad can allow entry through a PIN or other code.

Advantages include not requiring a physical card or smartphone. Disadvantages include the possibility of codes being shared, observed, or reused.

A system can reduce some risks through appropriate rate limiting, administrative controls, and the ability to revoke or change credentials.

Smartphone

A phone can function as a digital credential using technologies such as Bluetooth, NFC, or local networking.

An open system could avoid requiring a proprietary cloud account by allowing the phone to communicate directly with a locally controlled access server.

Multiple factors

Higher-security installations could require more than one form of authentication.

Examples might include:

• Card plus PIN.
• Phone plus local approval.
• Hardware token plus PIN.

The appropriate design depends on what is being protected and how much inconvenience is acceptable.

Controller hardware

An open keyless entry controller could use commonly available microcontrollers or single-board computers.

Possible platforms include:

• ESP32-class microcontrollers.
• Arduino-compatible boards.
• Raspberry Pi systems.
• Other Linux single-board computers.
• Custom open hardware controllers.

A small microcontroller may be sufficient for a single door operating locally.

A larger system involving multiple doors, centralized administration, databases, or advanced logging might use both embedded controllers and a local server.

Open designs can benefit from using readily available components that can be replaced without purchasing equipment from one manufacturer.

Locking mechanisms

Electronic access systems can control several forms of locking hardware.

Examples include:

• Electric strikes.
• Electrified deadbolts.
• Motorized locks.
• Magnetic locks.
• Electronic cabinet latches.

The mechanical and electronic parts should be considered separately from the authentication software.

A well-designed system should account for what happens during a power failure, fire alarm, network failure, controller failure, or damaged credential reader.

Depending on the location and application, building and fire codes may impose specific requirements on how doors unlock or remain secured during emergencies.

Local-first design

An open design keyless entry system could operate primarily on the local network rather than depending on a remote cloud service.

A local-first architecture could allow:

• Credential verification without Internet access.
• Local user management.
• Local event logs.
• Local configuration.
• Local backups.
• Integration with home automation systems.

Internet connectivity could remain optional.

This can increase resilience because loss of an Internet connection would not necessarily prevent authorized people from opening a door.

It can also provide greater control over access records and personal information.

Privacy

Access control systems can generate sensitive data.

A log might reveal:

• When a person entered.
• Which door was used.
• How frequently a person visits.
• Which credential was presented.
• Failed access attempts.

An open design should therefore make data collection visible and configurable.

Possible privacy principles include:

• Collect only information necessary for the intended purpose.
• Allow logging to be disabled or minimized where appropriate.
• Store records locally when practical.
• Define retention periods.
• Restrict administrative access.
• Encrypt sensitive data.
• Clearly document what information is stored.

The fact that a system can collect extensive data does not mean that it should.

Security by design

An access control system should assume that its hardware may be physically accessible to people outside the protected space.

Security therefore involves more than protecting a web password.

Important design areas include:

Secure credential handling. Protected administrative accounts. Encrypted network communication. Software update mechanisms. Tamper-resistant installation. Rate limiting. Secure storage of sensitive information.

Backup and recovery. Revocation of lost credentials. Security logs. Minimal exposed network services. Separation of reader and trusted controller functions. Regular security review. Documented threat models.

An open design can make these choices visible for inspection.

Open source does not automatically make a system secure, and proprietary software does not automatically make it secure either. Security depends on architecture, implementation, configuration, testing, maintenance, and the technologies being used.

Mechanical backup and failure modes

Electronic locks should be designed with failure in mind.

Questions include:

• What happens when electrical power fails?
• What happens when the controller crashes?
• What happens when the network is unavailable?
• What happens when a user loses a credential?
• What happens when the reader is damaged?
• How can authorized administrators regain control?

Some designs may retain a mechanical key as a backup. Others might include backup power or redundant controllers.

The system should also distinguish between fail-safe and fail-secure behavior.

A fail-safe system moves toward an unlocked condition during certain failures, while a fail-secure system generally remains locked. Which behavior is appropriate depends on safety requirements, building codes, and the purpose of the door.

User and permission management

A useful access system should make authorization easy to manage.

An administrator might need to:

• Add a user.
• Remove a user.
• Disable a lost credential.
• Assign access to particular doors.
• Limit access to certain times.
• Create temporary credentials.
• Review access events.
• Assign administrative roles.

For a makerspace, for example, one credential could provide building access while another permission allows operation of a particular machine.

This creates a connection between physical access control and identity management.

Integration with other open systems

An open keyless entry platform could communicate with other software through documented APIs or protocols.

Possible integrations include:

• Home automation.
• Alarm systems.
• Lighting.
• Building management.
• Membership databases.
• Reservation systems.
• Local identity systems.
• Machine access control.
• Notification systems.

Protocols such as MQTT are already used by some open access-control projects to communicate with home automation and other networked systems.

An open API can allow developers to build new interfaces without modifying the core controller.

Existing open source projects

Open access-control projects already demonstrate several aspects of this concept.

Prismo is an open-source NFC access controller designed for doors and machines. Its project publishes hardware and software and emphasizes self-hosting and inexpensive components.

ESP-RFID is another open access-control project using ESP8266 hardware with RFID readers, web-based configuration, MQTT integration, and support for electronic locking hardware.

Other projects have combined open software with ESP32, Arduino, Raspberry Pi, or custom PCBs.

These projects can be useful for studying existing approaches rather than beginning every design decision from the beginning.

Educational development project

An educational version could be developed gradually.

A first prototype might:

1. Read an NFC credential.
2. Compare it against a local authorized-user list.
3. Indicate whether access would be granted.
4. Operate a demonstration relay or indicator rather than a real door.
5. Provide an administrative interface.
6. Allow credentials to be added and removed.
7. Record optional test events.

After the basic system works, students could investigate stronger authentication, encrypted communication, local networking, backup power, logging, privacy controls, and integration with building automation.

Testing prototypes away from real security-critical doors makes it possible to experiment without making the prototype responsible for actual physical security.

Open manufacturing and repair

The hardware could also be designed for local fabrication.

An open enclosure could be manufactured with 3D printing, laser cutting, or CNC equipment.

PCB files could allow replacement controllers to be manufactured by different suppliers.

Standard connectors and modular components could simplify repairs.

This connects open keyless entry with distributed manufacturing, right to repair, and open design.

If one component becomes unavailable, the community could potentially redesign that component rather than replacing the entire access system.

Discussion questions, essay ideas, and learning related AI prompt ideas

• What components should be included in an open design keyless entry system?
• What advantages does open source access control have compared with proprietary smart locks?
• Should a keyless entry system require an Internet connection?
• What information should an access control system log?
• How long should access logs be retained?
• Which authentication technologies provide the best balance between convenience and security?
• When should a system be fail-safe versus fail-secure?
• Should a mechanical key remain available as a backup?
• How can a system continue working when its central server is offline?
• How should lost or stolen credentials be revoked?
• Ask an AI system to design a modular architecture for an open source keyless entry platform. Identify the controller, reader, credential, lock, database, and management components.
• Ask an AI system to compare RFID, NFC, smartphone, keypad, and hardware-token authentication from the perspectives of cost, privacy, reliability, and security.
• Develop a threat model for a hypothetical open access-control system without attempting to defeat a real access system.
• Design a privacy-preserving access log that records only the information actually needed by the organization.
• How could open source hardware make electronic access systems easier to repair and maintain?
• Could one open access platform control doors, lockers, shared equipment, and workshop machines?

Readings

Wikipedia

• Access control
• Electronic lock
• Smart lock
• Keyless entry
• RFID
• Near-field communication
• Multi-factor authentication
• Authentication
• Open-source hardware
• Home automation
• Internet of things
• Threat model

Existing open source projects and resources

• Prismo - Open-source NFC/RFID access-control hardware and software.
• ESP-RFID - Open source RFID access-control system for ESP8266-based hardware.
• Open Source Hardware Association: Open Source Hardware Definition

See also

Keyless entry Access control Electronic lock Smart lock RFID NFC Authentication Identity management Open source hardware Open source software

Open design Home automation Internet of things Cybersecurity Privacy Threat modeling Right to repair Distributed manufacturing 3D printing Problem solving