Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
This is a collection of ideas for student projects. Alternatively you are welcome to submit your own ideas. Please refer to the Getting Started page.
- Replacing OpenPGP Card with JavaCard
- Support for Universal 2nd Factor (U2F, FIDO Alliance)
- One Time Password Optimization
- Secure Firmware Update
- Migrate One Time Passwords to GNUK
- OpenCoin Wallet
- Nitrokey Storage Enhancements
Application and Integration
- Firmware Update Functionality for Nitrokey App
- Integrate Test Tool and Develop Test Cases
- GUI for Key Generation
- GUI and UX Optimization
- Nitrokey App to Support Multiple Devices
- Port Nitrokey App to Android
- Peaceful Coexistence of GnuPG With GNOME Keyring and Others
- Secure eCash Server Based on MirageOS
- OpenPGP.js Integration
- Linux LUKS Integration
- Improve Support in OpenSC
- PKCS#11 Cluster
- Nitrokey Device Emulation
- U2F Enhanced for End-to-End Crypto
- PGP-CA Bridge to Citizen ID Cards
- Fuzzy Testing with Google's OSS-Fuzz
Replacing OpenPGP Card with JavaCard
Description: JavaCard-platform may be more flexible than the current OpenPGP Card. Existing JavaCard apps should be evaluated, tested and (if required) improved. In focus are OpenPGP Card app including NFC, U2F app, OTP app.
Links: OpenPGP Card spec
- Get familiar with JavaCard platform and development environment
- Get familar with SmartPGP
- Build SmartPGP and test it
- Analyse the apps resource requirements
- Integrate several of them to run in parallel
Expected results: A set of apps for JavaCard.
Recommendation: If you are interested in programming smart cards, this is right for you.
Relevant Knowledge: Java, JavaCard, basic understanding of cryptography
Support for Universal 2nd Factor (U2F, FIDO Alliance)
Description: Implement support for the FIDO Alliance's U2F in Nitrokey Start, Pro, and/or Storage. It needs to be based on and be integrated to the given firmware. Good documentation and mature client software is available for testing. Firmware with FIDO U2F support for STM32 is available here. Also Tomu has a firmware originally for STM32 (but now ported to EFM32) with FIDO U2F support.
- Get familiar with the U2F specification
- Draft an approach to integrate U2F to the Nitrokey
- Implement U2F to the firmware
- Implement U2F support into the Nitrokey App
Expected results: A modified Nitrokey firmware with added U2F (dongle) functionality.
Recommendation: This is a nicely separated project which can be implemented from the beginning to end and be tested against given client software.
Relevant Knowledge: Embedded programming, C, basic understanding of cryptography
One Time Password Optimization
Description: Our current One Time Password (OTP) implementation has a few shortcomings:
- OTP tokens' length is too short to support 320 bit tokens
- The code quality can be improved (e.g. by removing pointers)
- The challenge-responds version of OTP called OCRA isn't supported The objective of this project is to fix these shortcomings.
- Refactor the code and comply to Nitrokey's code styles
- Increase the maximum length of OTP tokens to 320 bit.
- Add OCRA feature to OTP (You can use LinOTP as a reference implementation. )
- Update the client tool to support OCRA
Expected results: A modified Nitrokey firmware with improved OTP functionality. Enhanced Nitrokey App to support OCRA.
Recommendation: This project is for students who know how good code looks like and who don't mind to dig into existing code.
Relevant Knowledge: Embedded programming, C, basic understanding of cryptography
Details for 320 bit tokens:
Current values, prior to change:
- STM32: page size 1024 Byte
- AVR: page size 512 Byte
In Nitrokey Pro 2 pages are used. The layout is:
- Global configuration: 64byte
- 3 HOTP slots x 64byte
- 15 TOTP slots x 64byte
- TOTP effective data usage per slot: 52 Byte
- TOTP actual reserved space per slot: 64 Byte
- TOTP free space per slot: 92 bit
- TOTP secrets: 160 bit
- for 320 bit secrets we require additional 68 bit per slot
Free space: 832 bytes
Flash space optimization:
- Merging slot configuration with the "used flag" -> saves us 1 byte per slot
- Use spare 92 bit (11.5 byte) per slot
Secure Firmware Update
Description: The purpose is to prevent (or make it more difficult) flashing of malicious firmware when an attacker has access to the device for a short time. Legitimate firmwares would be signed with a firmware signing key. Nitrokey would be shipped with the public signing key. User downloads a signed firmware update for their device, and loads it onto the Nitrokey. Nitrokey verifies the signature, ensuring that the firmware is authentic. If it is, the firmware updates itself, otherwise it rejects it. The entire logic might be implemented in a separate boot loader either for the current STM32-based Nitrokey Pro or for the new Nitrokey Storage which is Atmel AT43UC-based.
- Get familiar with Nitrokey's firmware.
- Decide for a bootloader to use
- Get the bootloader running
- Integrate hash- and RSA signature verification functions
- Implement load-firmware function
- Change Nitrokey App to send new firmware to Nitrokey device
Expected results: A modified Nitrokey firmware enhanced by secure firmware functionality. Enhanced Nitrokey App to trigger the secure firmware update.
Recommendation: This project requires significant research and designing a solution prior to the actual implementation. Its for students who are already familiar with this type of embedded programming.
Relevant Knowledge: Embedded programming, microprocessors, C, Assembler, basic understanding of cryptography
Migrate One Time Passwords to GNUK
Description: Migrate the existing One Time Password (OTP) feature to GNUK. OTP is a two-factor authentication mechanism which got some traction. It works with Gmail, Google Apps, Facebook, Dropbox, AWS and more. We implemented OTP on Nitrokey's firmware during GSOC 2012. Now we are planning to port this feature to GNUK firmware as well. GNUK will be used as a basis for Nitrokey Light. Both systems are STM32 based.
- Get familiar with Nitrokey's firmware and GNUK.
- Integrate USB Composite Device to GNUK
- Migrate the OTP functions from Nitrokey to GNUK
Expected results: An enhanced version of GNUK supporting OTP additionally.
Relevant Knowledge: Embedded programming, C, basic understanding of cryptography
Description: Similar to a BitCoin wallet, build a hardware wallet for OpenCoin's digital cash system. Its purpose is to protect the cash in the hardware device and render malware useless. Nitrokey Pro's STM32 or JavaCard are suggested as a hardware platform.
- Plan the architecture
- Discuss and agree on an approach with mentor
- Implement the firmware
- Implement a client tool as a GUI to manage the hardware wallet
- Test against a given server
Expected results: A firmware and client which both together work as a secure wallet for OpenCoin.
Relevant Knowledge: Embedded programming or JavaCard, C or Java, basic understanding of cryptography
Nitrokey Storage Enhancements
Description: The Nitrokey Storage is our Atmel-based device. Its firmware should be enhanced with the following functionality:
- The firmware compiles with Atmel's own compiler on Windows. Create Makefiles (and potentially do necessary changes to the source) so that it compiles with GCC. (This might help.)
- The encrypted volume of the Nitrokey should be automatically locked when the volume is idle for 10 minutes. Some operating systems regularly access the filesystem. An algorithm should be developed to detect when the volume is idle and unrelevant accesses to the volume should be recognized.
- Hidden volumes should be created without damaging data on the primary encrypted volume. This requires to recognize the available areas of the volume. An algorithm should be developed to detect the maximum available space of the volume without damaging any data.
- Get familiar with the firmware of Storage
- Test how different operating systems and different file systems are accessed
- develop solutions and agree with mentor
Expected results: Modified Storage firmware. It compiles with GCC and is enhanced with the agreed solutions (algorithms) for the two described problems.
Relevant Knowledge: Embedded programming, C, good algorithmic thinking
Application and Integration
Firmware Update Functionality for Nitrokey App
Description: Develop a solution to update the firmware from the Nitrokey App, so that the user doesn't need to use a third party tool for updating.
- Until now the dfu-programmer was used. Get familiar with it's source code and extract the needed functionality
- Integrate the functionality into the App
- Add an auto-update functionality to the Nitrokey App itself. Whenever a new binary is published on the project website, the App should notify the user and (after a user confirmation) automatically update itself. This functionality should be disabled when the App is packaged as part of a Linux distribution.
Expected results: Enhanced Nitrokey App which automatically checks for available updates and (after confirmation) updates the Storage firmware and itself.
Relevant Knowledge: C++
Integrate Test Tool and Develop Test Cases
Description: So far no proper unit tests are used. This project aims to fix the situation and to develop unit tests and end-to-end tests. The tests would be implemented and performed on the PC only and call the Nitrokey App or GnuPG. They require the Nitrokey device to be connected but would not be implemented in the firmware directly.
A first draft of relevant test cases:
- Generate keys of various key sizes
- Import keys of various key sizes
- Change PINs
- Edit Card Preferences (e.g. name, url, language)
- Retrieve Card Status
- Reset Card
- One Time Passwords / Password Safe
- Add Account
- Generate OTP/password
- Change Account
- Delete Account
- Protect by PIN
- Storage usage
- Connect unencrypted volume
- Unlock encrypted volume
- Setup hidden volume
- Unlock hidden volume
- Delete volumes
- Storage Device Configuration
- Flash Firmware
- Factory reset device
- Retrieve status information
- Select a test tool, e.g. http://cpputest.github.io/
- Identify useful end-to-end tests
- Identify useful unit tests of the client-side App
- Implement the identified test cases
- Integrate the test tool, so that tests are performed automatically after each commit.
Expected results: A fully applicable suite of tests which covers all relevant cases, integrated into the dev/build infrastructure.
Recommendation: For students who know about testing and don't want to dig into the embedded system.
Relevant Knowledge: C++, testing
GUI for Key Generation
Description: An easy-to-use and error-free way to generate keys on the device is lacking. The goal should be to implement a GUI which allows users to easily generate keys on the Nitrokey and allowing a full backup of their keys. The tool should be preferably integrated to Nitrokey App (a wizard dialogue within Nitrokey App). The tool should check if access to smart card is available or if another application (e.g. gpg-agent, scdaemon, opensc) is blocking the device. In case it should inform the user about it. Next it should display a dialogue where users can enter their personal data (e.g. name, email address) and select key characteristics (e.g. algorithm, key length, backup: yes/no). After confirmation it should start generating the keys. If backups are enabled, it should prompt the user to enter a password to encrypt the key backup. Finally it should inform the user about success (or failure) of key generation.
- Understand Nitrokey App and 3rd party tools (e.g. GnuPG, SCDaemon, OpenSC)
- Choose a way to communicate with the smart card (e.g. GnuPG, SCDaemon, OpenSC, pcscd, openpgp-tool, Gnuk's Python scripts, own implementation)
- Implement and test process on different operating systems and with different tools installed.
- Create dialogues in Nitrokey App and integrate process.
- Add required dependencies to Nitrokey App
Expected results: An improved Nitrokey App with wizard for easy-to-use key generation
Relevant Knowledge: QT and C++. An understanding of OS daemons, GnuPG and OpenSC would be helpful.
GUI and UX Optimization
Description: This idea is a collection of various sub-ideas and it is a starting point to decide for a specific topic later on. The Nitrokey App allows administrating and using the Nitrokey. It's based on QT5 and runs on Linux, Windows and MacOS. The App's look and feel should be improved to a perfect look and to provide a super-easy user experience (UX).
- Take a look to the existing tickets, the ones related to UI and UX.
- Add a "wizard" to configure OTPs. This could including a screen reader to scan QR codes displayed in the web browser for easy configuration.
- Paste OTPs directly: Users should have the configurable option: instead of copying a OTP to the clipboard the Utility should paste the selected OTP directly into the curent cursor position.
- In Nitrokey App's dialogues, add small question mark icons next to each setting, which displays a short explanation of the particular setting when the mouse is pointing or clicking on it.
- Analyse the entire work flow, dialogues and texts and improve those with a les confusing work flow, clear language and helpful dialogues.
Expected results: An improved Nitrokey App with awesome look and feel.
Relevant Knowledge: UI and UX design; QT and C++ would be useful
Nitrokey App to Support Multiple Devices
Description: Design and develop a clear solution to manage multiple Nitrokey devices from the App simulatnously. Possible solutions could be:
- Multiple instances of the App. Use some system sharing mechanism to decide which device is communicating with which App instance
- Manage from one App. This approach will need to create an abstraction of the 'device', and proper refactoring of the App will follow.
Expected results: Modified Nitrokey App which works with two and more devices in parallel.
- Understand how App and device communicate
- Design and agree to a solution with the mentor.
Relevant Knowledge: C++
Port Nitrokey App to Android
Description: The Nitrokey App allows administrating and using the Nitrokey. Nitrokey App 1.0 runs on Linux, Windows and macOS and consists of a library for the device communication and a QT5-based GUI. The App should be migrated to Android which includes changes to the GUI and maybe the underlaying system. This is an "early stage idea" and we haven't researched it very much. This and that links may be a starting point and the Guardian Project may have some thoughts on this topic too. Note that OpenKeychain has basic support for Nitrokey already. This project is primarily about functionality to use and manage the NK Storage.
- Plan how the GUI should look like; create mockups.
- Analyze system dependencies and necessary changes
- Migrate libnitrokey to Android
- Build a GUI based on libnitrokey
- Package for F-Droid app store
Expected results: A (potentially feature-reduced) version of Nitrokey App which can be installed on Android.
Relevant Knowledge: C++, QT, Android
Peaceful Coexistence of GnuPG With GNOME Keyring and Others
Description: This has been a major issue in the GnuPG and smartcard ecosystem for many years. Currently two significant problems occur when using GnuPG with smartcards:
- GnuPG takes exclusive access of the smartcard, thus all the other application cannot use it at the same time
- There is a collision between GnuPG and gnome-keyring-daemon. The workaround until now it to kill gnome-keyring-daemon. There has been discussions in the web how this problem should be fixed properly. Different opinions exist. Part of this project is to design the solution. This requires considering the involved program maintainers who need to accept the patch later on.
- Get familiar with the necessary parts of GnuPG and gnome-keyring-daemon source
- Change GnuPG's exclusive access to shared access
- Research and test for possible implications of the shared behaviour (eg: while generating keys). Maybe some scenarios really need an exclusive access scheme. Do performance tests.
- Find a proper solution for the gnome-keyring-daemon issue
- Get in touch with the GnuPG and Gnome developers and push your patches
- A tested patch for GnuPG (for non-exclusive access) which is accepted by maintainer or has good chance of being accepted. This includes test convincing test results.
- Patches to solve the GPG+gnome-keyring issue with good change of maintainers acceptance.
Relevant Knowledge: C, Linux
Secure eCash Server Based on MirageOS
OpenCoin is a related open source project to build an anonymous digital cash system. MirageOS is a unikernel for secure and small dedicated systems. This project is to implement a secure server for OpenCoin based on MirageOS and integrate the Nitrokey. The server would perform the following activities: receive a token, verify its integrity, create a new token, sign it by calling the Nitrokey, store the old token in an external DB, send back the new token.
- Get familiar with the OpenCoin protocol and MirageOS
- Agree the architecture with mentor
- Implement the external web interfaces
- Implement JSON parsing and token structures etc.
- Implement SHA2 hashing and RSA signature validation, preferrable by utilizing existing libraries.
- Integrate Nitrokey (e.g. device driver)
- Documentation, testing
Expected results: A server implementation with security in mind, which works according to the OpenCoin spec and with its client.
Relevant Knowledge: MirageOS, Ocaml, Web services, Basic understanding of cryptography
Mailvelope / OpenPGP.js Integration
- Get familiar with OpenPGPjs and the patch
- Rebase patch to latest OpenPGPjs version
- Update Firefox add-on and provide comprehensive test case
- Submit merge request and agree with OpenPGPjs community on further changes required
Expected results: A patch to OpenPGP.js and its Firfox Addon which enables the usage of Nitrokey devices for cryptographic operations within OpenPGP.js.
Linux LUKS Integration
LUKS is a file system encryption solution for Linux. It should be enhanced so that it can be unlocked with the Nitrokey. An important aspect is, that for full-disk encryption of the PC's harddrive the Nitrokey would need to be used in pre-boot stage. At the current time the way to go is not clear and you would need to do some research first before starting implementation.
- Research and evaluate existing options. (e.g. TokenTube is a pre-boot enhancement to LUKS.)
- Identify an approach how to bring in smart card support into pre-boot stage.
- Develop and agree plan to improve.
- Implement and test improvements.
- Create packaging for Linux distributions.
- Create user documentation incl. screen shots.
Expected results: Patches to LUKS or other related system software (e.g. PAM). Software package which includes the patched software. Instructions how to use Nitrokey with LUKS.
Relevant Knowledge: C, Linux
Improve Support in OpenSC
Description: OpenSC is the dominant open source PKCS#11 and PKCS#12 framework. It has support for Nitrokey with OpenPGP Card 2. It also has basic support for the new OpenPGP Card 3 but lacks support for its new features. OpenSC should be updated to fully support OpenPGP Card 3.
- Get familiar with OpenSC and its internal OpenPGP Card driver
- changing DOs' names and access if needed
- adding DOs for future work
- setting PIN length to 64 bytes
- Adding support for Elliptic curves
- Adding support for Managed Security Environment (MSE)
- Testing, especially MSE
- Incorporating feedback from OpenSC's maintainer to get changes approved
Expected results: Several accepted pull request to OpenSC
Relevant Knowledge: C, PKCS#11, smart cards
Simple PKCS#11 wrapper which schedules work among several Nitrokey (or other PKCS#11 smart cards).
Purpose: To distribute signing/encryption tasks on a high-load server among several Nitrokeys efficiently without requiring a modification of the application. The wrapper should in fact be a PKCS#11 module itself so that it can be loaded by any application which supports PKCS#11.
Structure: Application (e.g. Apache) <-> this PKCS#11 wrapper <=> several PKCS#11 Nitrokey driver (OpenSC) <=> several Nitrokey devices (hardware)
Functionality: At startup all available Nitrokeys are detected. For the wrapper each device has an individual slot number but for the application it looks like a single device.
A call of a PKCS#11 function (by the application) will be scheduled according to the following approach: The wrapper keeps a list of all available devices (their slots) and their state (busy, idle, optional: verified+idle). A new request (from the applicaction) is send by the wrapper to the next idle device. The list schedules the work even among the connected Nitrokeys, not always to the first one. If possible the wrapper always takes an idle device but doesn't wait for a device to become available. I understand the response would be linked to the appropriate request by the threat. Hence, the wrapper should be multithreaded.
Discussion point: I think the APDU flow is: a Verify command comes first and afterwards a Sign or Encrypt command. If this is the case the internal list may need to use the third state verified+idle. The purpose of this state is that a Sign or Encrypt command is only send to a device which is verified already. If this is not the usual behaviour and instead the PIN comes together with the actual command, the third state may not be necessary. In other words:
State flow A): idle --(verify)--> idle+verified --(sign/decrypt)--> busy --(retrieve response)--> idle
State flow B): idle --(verify+sign/decrypt)--> busy --(retrieve response)--> idle
Exception case: If a request from the application is received and no device is idle, I think the wrapper should report an error message back to the application, according to PKCS#11 specification. But you may suggest a better behaviour.
Commands: Primarily I see Verify, Sign, and Encrypt commands. Key generation command should be rejected ("not allowed in cluster mode") because it would result in an inconsistent state where one device has another key than the others. Commands to initialize/configure the Nitrokey are optional and may be ignored if this reduces the implementation effort. Please advise.
The wrapper should utilize OpenSC (link the PKCS11 driver). In fact PKCS#11 Helper might be the right tool to integrate this feature. It should be assumed that all Nitrokeys are equipped with identical keys and passwords.
- Init parameter: path to load any PKCS#11 driver. Rather than Nitrokey specific, use any PKCS#11 device for the given driver
- Init parameter: path to configuration file which specifies the allowed and disallowed devices by serial number as well as default behaviour (accept or reject new devices)
- Connected and disconnected devices are detected online without restarting the wrapper
- Configuration/initialization of all devices within a cluster
Expected results: Patches to OpenSC which enable the usage of a smart card cluster.
Relevant Knowledge: C, smart cards
Nitrokey Device Emulation
Description: Develop an emulated Nitrokey device. The emulated device should work as if a real device was plugged-in to the host.
- Research possible designs and solutions. One possible solution is to use Qemu (and QDEV). Another could be to create a linux device driver.
- Implement the OpenPGP smartcard functionality. Gnuk project might be a good starting point for this.
- Integrate Nitrokey's firmware with the software-only OpenPGP smartcard.
- Implement a device driver or qemu device (depending on the chosen approach) and test
Expected results: Modified Nitrokey firmware, modified GNUK and instructions how to integrate these.
Relevant Knowledge: C, embedded programming
U2F Enhanced for End-to-End Crypto
- Research the given U2F specification and previous related discussion (e.g. in W3C working groups)
- Design a solution and agree with mentor
- Patch a given U2F implementation of a virtual dongle
- Patch a given browser support or provide browser add-on
Recommendation: This is for students with strong architectural and abstract thinking.
PGP-CA Bridge to Citizen ID Cards
Description: The Web of Trust is used for OpenPGP. Some official ID cards allow verifying the owners identity in the web. This project is about building a server which signs PGP keys for citizens based on their ID cards. This project utilizes another cloud service, Skidentity, which provide such verification for a number of ID cards already. The signing key will be stored on a Nitrokey which would need to be integrated. The server should be implemented with security in mind. For this it would be great but not required to use MirageOS which is written in Ocaml.
- Develop use-cases, using mockups for instance.
- Develop a policy for the key handling of the PGP-CA
- Make yourself familiar with Skidentity's API
- Implement the server
Expected results: A fully working server implementation. A policy for key handling.
Recommendation: This is for students with strong security and cryptography focus.
Relevant Knowledge: Cryptography, Web programming, preferred: Ocaml
Fuzzy Testing with Google's OSS-Fuzz
Description: Background: OSS-Fuzz.
The idea of fuzzy-testing looks appealing and it might find a use in libnitrokey and firmware projects. Having however hardware-based project it could be difficult to introduce it because of the problem of simulating the device's responses - fuzzy-test in its nature does hundreds/thousands of tests per second (so direct communication with the device or through networking cannot be taken into account due to 50-100ms+ processing lag).
It would be best to run simulated device on either some VM (some QEmu fork seems to support STM32) or compiled natively (with some additional communication instead of hidapi). Both ways though would require simulation of SIM card responses, replying with recorded ones or skipping SIM related tests altogether.
Another idea is to write a simple mocking class representing the device for the libnitrokey and run fuzzy-tests against it. This would have more advantages of making it possible to run tests on CI servers, isolating from hardware and making it possible to develop a software with a device without having it physically, but would come with a initial cost of writing the mock and later updating it.
As for Nitrokey App, I would have to see Qt GUI App automated testing first.