Virtual Smart Card Architecture: one umbrella over five smart card emulators

The top level is an index, and the substance is five directories down

The README is short and its first line states what the whole thing is: Virtual Smart Card Architecture is an umbrella project for various projects concerned with the emulation of different types of smart card readers or smart cards themselves.

That word umbrella sets the expectation correctly. The repository does not build one program. It holds five projects, and the README lists them with a link to each of their own pages: Virtual Smart Card, Remote Smart Card Reader, Android Smart Card Emulator, PC/SC Relay and USB CCID Emulator. The site is at frankmorgner.github.io/vsmartcard, and the README directs readers there for more information.

The top level listing confirms the structure. Alongside the README, a .github directory, a .gitignore, a .gitmodules file and a .travis.yml, there are eleven directories that map onto the umbrella's scope. The five named subprojects appear as virtualsmartcard, remote-reader, ACardEmulator, pcsc-relay and ccid. The remaining six are TCardEmulator, android-ssl1, eID_gui, npa, doc and docs.

The .gitmodules file is the mechanism, and it matters. A submodule is a pointer to another Git repository at a specific commit, checked out inside a directory of this one. That is how an umbrella project aggregates several independent codebases without copying them, and it also means that building the umbrella is a matter of getting five separate projects at the right versions, each with its own build system and its own dependencies. The TCardEmulator directory sitting alongside the named five suggests a related component that the README does not list among the member projects.

So the practical first step for anyone evaluating this is not to read the umbrella README, which is what most people will do, but to pick the subproject that matches the problem and read that.

Each member project covers a different link in the chain

The five subprojects map onto the distinct pieces of a smart card system, and the split tells you what the project is for.

Virtual Smart Card is the core: a software smart card that presents itself to the operating system's PC/SC stack as though it were a physical card. Remote Smart Card Reader does the same for the reader side, letting a card on one machine be reached as a reader on another. Android Smart Card Emulator does it on a phone, which is what makes it useful for writing and testing Android NFC applications. PC/SC Relay bridges the PC/SC interface, letting applications talk to a reader that is not a local one. USB CCID Emulator works at the layer below PC/SC, presenting a USB CCID device to the operating system so that any CCID-aware stack can use it.

The layering is the point. The USB CCID emulator is the lowest layer, because it pretends to be hardware. The virtual smart card sits at the PC/SC layer. The remote reader crosses a machine boundary. The Android emulator replaces the card in a phone. The PC/SC relay is the general-purpose bridge for the cases where the application and the card are not on the same machine.

That is why this is an umbrella rather than a product. A developer building a smart card test rig, an NFC application for a phone, or a system where a physical card has to be shared between machines needs a different one of these five, and building all of them on a shared understanding of the layers is the argument for keeping them under one roof.

The primary language on the project record is C, which fits: the lowest layer here is a USB device, and the topics attached to the repository list ccid, pcsc, nfc, smartcard, smartcard-reader, android, security and tizen-wearable, along with python, which points to tooling rather than to the core implementation.

Three CI systems, and what that tells you about the platforms

The README carries three build badges and they describe the shape of the project better than any prose could.

There is a GitHub Actions CI status badge labelled Ubuntu and macOS, pointing at a workflow called ci.yml on the master branch. There is an AppVeyor CI badge labelled Windows. And there is a Coverity Scan badge, pointing at a Coverity project.

So the project is built on three operating systems, and the Coverity badge indicates that at least one component is under static analysis with a commercial scanner. For a codebase that parses and emits low level smart card protocols and presents itself to an operating system's PC/SC driver, having a static analyser in the loop is a reasonable thing to want, and having three build systems rather than one suggests the components have genuinely different platform requirements. A USB device on Linux, a PC/SC driver on Windows and an Android app are not the same build problem.

The presence of a.travis.yml alongside the GitHub Actions workflow is the one historical artefact. The project has migrated from Travis to GitHub Actions, and the old configuration file is still in the tree, which is the usual sign of a long-lived project rather than a recent one.

The release record supports the same reading of a project that has been running for years. The recent releases are virtualsmartcard-0.11 on 2026-09-18, ACardEmulator-4.0 on 2026-09-09 and virtualsmartcard-0.10 on 2025-03-27. The version numbers are per-subproject and they do not move in step: virtualsmartcard is on 0.x while ACardEmulator has reached 4.0, which is exactly what you would expect from an umbrella whose components have independent histories and independent maintainers.

The last push to the repository was on 2026-10-21 and it is not archived.

What emulation buys you, and where it stops

The value of this project is in a specific set of situations, and the documentation does not oversell them.

A virtual smart card lets a PC/SC application believe it is talking to a card when it is not. That means the authentication, the PIN handling, the file system operations and the applet selection in your application can be exercised in a test suite, on a build machine, without issuing physical cards and without a reader on the desk. The same applies in reverse to a reader: a remote reader lets an application on one machine drive a card plugged into another, which is how a physical card can be shared between a test rig and a build.

On Android, the emulator is what lets you develop an NFC application before the hardware is in your hand, and the tizen-wearable topic on the repository suggests the wearable case is considered too.

Where the approach stops is at the security boundary. An emulated card is a software card running on the same machine as the application that uses it, so it provides no protection against an attacker who already has that machine. It is a development and testing tool, and the useful thing about it is that the test looks exactly like the real thing at the API level, so the application code does not need a test-only branch. The applications list does not claim otherwise.

The second boundary is the layer below. The USB CCID emulator presents a device to the operating system, which means it must be installed and trusted at the system level, and the operating system has to have a CCID driver that will accept it. On Linux that is usually straightforward because the driver stack is in the kernel and the interface is a documented one. On other platforms, the amount of work in front of the emulator grows, and the umbrella structure means you take on that platform problem for the component you choose, not for the whole set.

The third boundary is the maintenance reality of an umbrella. There is no single version of the whole system, no single build, and no compatibility statement that covers all five. When you adopt one of these, you are adopting that project's release cadence, and the umbrella only guarantees that they live in the same place.

The licence is the first thing to settle

The project record lists the licence as unknown, and the top level repository listing contains no licence file. Alongside the README, the .github directory, the .gitignore, the .gitmodules and the .travis.yml, and the eleven project directories, there is nothing named LICENSE.

That is a genuine adoption question rather than a technicality. Every subproject may carry its own licence file, since each is a separate repository that this one points at, and the subprojects are the code you would actually compile. But the umbrella itself, the thing that holds the pointers and the documentation, is unlabelled.

The practical advice is narrow and specific. Read the licence file of each subproject you intend to build, because that is the code that ends up in your product, and the umbrella's own status does not tell you anything about it. And if your compliance process needs a licence on the repository you are cloning, that check will fail here, which is a fact to establish before you clone rather than after.

This is also the kind of gap that is easy to misread as a deliberate choice. The project is by a single long-standing author whose own work in the smart card and NFC space predates most of the current tooling, and the site is hosted on a personal GitHub Pages domain rather than an organisation domain. For a project like that, a missing top level licence file is more likely to be an oversight than a statement, but the effect on a adopter is the same either way, because the terms are not written down where you would look for them.

Everything else about the project's posture is visible and positive. The work is open, the CI runs on three platforms, a static analyser covers part of it, and the components are independently versioned with recent releases in 2026. What is missing is the paperwork, and for a security-adjacent codebase that is where the care is needed.

Editorial conclusion

The Virtual Smart Card Architecture fits a developer who needs a card or a reader that does not physically exist, in particular for testing PC/SC and NFC code paths, for driving a card on another machine, and for building Android NFC applications without a physical card. It is the wrong choice if you need a single installable tool, because the components are separate projects with their own documentation, and it is the wrong choice if you need a commercial smart card driver, since this emulates the infrastructure rather than implementing a card. Before adopting it, read the subproject documentation rather than the umbrella README, and check the licence, because the project record lists the licence as unknown and the repository listing contains no licence file, which is an unusual position for code you intend to build on.

Frequently asked questions

Official sources

1. frankmorgner/vsmartcard on GitHub
2. Issues
3. Project website
4. README
5. Releases