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.

• JavaCard Applet for FIDO2
• Replacing OpenPGP Card with JavaCard
• Add Support for FIDO
• Secure Firmware Update
• Migrate One Time Passwords to GNUK
• Taler Wallet
• Nitrokey Storage Enhancements

• Use FIDO2 as Password Manager
• Firmware Update Functionality for Nitrokey App
• 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

• Improving NitroHSM
• Secure eCash Server Based on MirageOS

• FIDO2-Based Password Manager as Browser Add-On
• Web UI for Key Management with NitroHSM
• JavaScript Integration

• Linux LUKS Integration
• Improve Support in OpenSC
• PKCS#11 Cluster
• Integrate Test Tool and Develop Test Cases
• Nitrokey Device Emulation
• FIDO Enhanced for End-to-End Crypto
• PGP-CA Bridge to Citizen ID Cards
• Fuzzy Testing

Description: JavaCard-platform may be more flexible than the current architecture. A Javacard applet should be written to support FIDO2.

Tasks Involved:

• Get familiar with JavaCard platform and development environment
• Get familar with FIDO2 specification
• Analyze existing FIDO U2F JavaCard applet if it is a good starting point to be extended.
• Implement the FIDO2 protocol incl. PIN authentication

Expected results: A JavaCard applet for FIDO2

Recommendation: If you are interested in programming smart cards, this is right for you.

Priority: High

Difficulty: High

Relevant Knowledge: Java, JavaCard, basic understanding of cryptography

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

Tasks Involved:

• Get familiar with JavaCard platform and development environment
• Get familar with SmartPGP
• Build SmartPGP and test it
• Analyse the apps resource requirements
• Select Javacard applets for OTP and FIDO
• 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.

Priority: medium

Difficulty: High

Relevant Knowledge: Java, JavaCard, basic understanding of cryptography

Description: Implement support for the FIDO2 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. But most importantly our own dedicated device. Merging the later one would require hardware modification.

Links: 1, 2, 3, 4

Tasks Involved:

• Get familiar with the FIDO2 specification
• Select Nitrokey Pro, Start or Storage as a target device
• Draft an approach to integrate FIDO2 to the Nitrokey and discuss with team
• If required, prepare hardware changes (this could be done by rest of the team)
• Implement FIDO to the firmware
• Test

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.

Priority: High

Difficulty: High

Relevant Knowledge: Embedded programming, C, basic understanding of cryptography

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.

Links: 1, 2, 3, 4, 5

Tasks Involved:

• 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
• Test

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.

Priority: Medium

Difficulty: High

Relevant Knowledge: Embedded programming, microprocessors, C, Assembler, basic understanding of cryptography

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.

Tasks Involved:

• Get familiar with Nitrokey's firmware and GNUK.
• Integrate USB Composite Device to GNUK
• Migrate the OTP functions from Nitrokey to GNUK
• Test

Expected results: An enhanced version of GNUK supporting OTP additionally.

Priority: Medium

Difficulty: Medium

Relevant Knowledge: Embedded programming, C, basic understanding of cryptography

Description: Similar to a BitCoin wallet, build a hardware wallet for Taler'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.

Tasks Involved:

• 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 Taler.

Priority: Low

Difficulty: High

Relevant Knowledge: Embedded programming or JavaCard, C or Java, basic understanding of cryptography

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.
• More bugs and enhancements are documented here.

Tasks Involved:

• Get familiar with the firmware of Storage
• Test how different operating systems and different file systems are accessed
• develop solutions and agree with mentor
• Implement
• Test

Expected results: Modified Storage firmware. It compiles with GCC and is enhanced with the agreed solutions (algorithms) for the two described problems.

Priority: Medium

Difficulty: High

Relevant Knowledge: Embedded programming, C, good algorithmic thinking

Description: FIDO2 is a protocol where token sign authentication requests with side-specific private keys. This mechanism should be exploited to generate site-specific passwords. Similarly to a master password scheme with the difference, that FIDO2 uses one key per site. Goal of this project is to integrate such solution into Nitrokey App which utilizes a FIDO2-compatible device as a password store for websites (and applications) which don't support FIDO2 but which require ordinary static passwords.

Tasks Involved:

• Get familiar with FIDO2, Qt, and Nitrokey App
• Utilize a given library to interact with the FIDO2 device
• Design a solution to derive the static passwords as described
• Draft the GUI and integrate that solution into Nitrokey App

Priority: High

Difficulty: Medium

Relevant Knowledge: C++, Qt, FIDO, cryptography

Description: Merge the separate Nitrokey Update Tool to the Nitrokey App, so that the user doesn't need to use a separate tool for updating.

Tasks Involved:

• Get familiar with Nitrokey Update Tool's source code and its dependencies
• Integrate the functionality into the Nitrokey App
• Add required menus and dialogues into App
• Test
• 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.

Priority: Medium

Difficulty: Low

Relevant Knowledge: C++

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.

Tasks Involved:

• 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

Priority: Medium

Difficulty: Low

Relevant Knowledge: QT and C++. An understanding of OS daemons, GnuPG and OpenSC would be helpful.

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).

Potential sub-ideas:

• 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.

Priority: Medium

Difficulty: Low

Relevant Knowledge: UI and UX design; QT and C++ would be useful

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.

Tasks Involved:

• Understand how App and device communicate
• Design and agree to a solution with the mentor.
• Implement
• Test

Priority: Low

Difficulty: Medium

Relevant Knowledge: C++

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.

Tasks Involved:

• 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
• Test

Expected results: A (potentially feature-reduced) version of Nitrokey App which can be installed on Android.

Priority: Low

Difficulty: Medium

Relevant Knowledge: C++, QT, Android

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.

Tasks Involved:

• 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

Expected results:

• 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.

Priority: Low

Difficulty: Medium

Relevant Knowledge: C, Linux

Description: NitroHSM/keyfender is a HSM software implementation written in type-safe OCaml and build into a unikernel with MirageOS. These properties allow to build highly-secure systems. At the current stage the implementation is a working prototype and needs to be improved and enhanced on various angles. Please contact us if you are interested in working on NitroHSM.

Tasks Involved:

• Get familiar with OCaml, MirageOS

Priority: High

Difficulty: Medium

Relevant Knowledge: Functional Programming

Taler 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 Taler 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.

Tasks Involved:

• Get familiar with the Taler 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, preferable 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 Taler spec and with its client.

Priority: Low

Difficulty: High

Relevant Knowledge: MirageOS, Ocaml, Web services, Basic understanding of cryptography

Description: Same as the idea use FIDO2 as password manager but as a browser add-on instead of an integration to Nitrokey App. The browser add-on should utilize WebAuthn interface and should support most current browsers.

Priority: High

Difficulty: Medium

Relevant Knowledge: JavaScript, FIDO2, cryptography

Description: NitroHSM/keyfender is a HSM software implementation to generate, import, store, and use cryptographic keys. It provides a REST API which can be used by a Web application for managing keys and to configure the system. An early prototype of the Web UI has been written with vue.js. This prototype should be enhanced to cover the entire REST API.

Tasks Involved:

• Get familiar with vue.js and NitroHSM's API
• Draft UI and UX
• Incrementally implement available API calls

Priority: High

Difficulty: Low

Relevant Knowledge: JavaScript, REST

Description: This project's goal is to update an old patch for OpenPGP.js and a related Firefox Add-on. The patch enhances OpenPGPjs with a smart card interface which is usable with the Nitrokey. OpenPGPjs is an Open Source OpenPGP library in JavaScript so it can be used on virtually every device. It shall implement all the needed OpenPGP functionality in a JavaScript library, to reuse it in other projects and to provide example applications and browser plugins. It should allow to sign, encrypt, decrypt, and verify any kind of data - in particular emails - as well as managing keys. Examples are Mailvelope, a browser plugin supporting various webmail services, and rc_openpgpjs which enhances the webmail system Roundcube by email encryption capabilities. The patch being available is a working prototype which needs updates and improvements to become mature.

WebUSB based Authentication using CCID project is promising approach and should be evaluated as an alternative approach to above description.

Web2Native Bridge is another similar project but requires Java.

Tasks involved:

• 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 Firefox Addon which enables the usage of Nitrokey devices for cryptographic operations within OpenPGP.js.

Priority: High

Difficulty: Medium

Relevant Knowledge: JavaScript, Firefox add-ons, basic understanding of cryptography

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. See also

Tasks involved:

• 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.

Priority: Low

Difficulty: High

Relevant Knowledge: C, Linux

Description: OpenSC is the dominant open source PKCS#11 and PKCS#12 framework. It has support for Nitrokey with OpenPGP Card but lacks support for its new features. OpenSC should be updated to fully support OpenPGP Card 3.

Tasks Involved:

• Get familiar with OpenSC and its internal OpenPGP Card driver
• setting PIN length to 64 bytes
• Make the device's TRNG usable through OpenSC
• Incorporating feedback from OpenSC's maintainer to get changes approved
• Expand documentation regarding the new features
• Support multiple certs (see #1339)

Tasks done so far:

• Adding support for Elliptic curves #1506

Expected results: Several accepted pull request to OpenSC

Priority: High

Difficulty: Medium

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.

Optional:

• 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.

Priority: Low

Difficulty: High

Relevant Knowledge: C, smart cards

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:

• GnuPG
• 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

Tasks Involved:

• 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.

Priority: Medium

Difficulty: Low

Relevant Knowledge: C++, testing

Description: Develop an emulated Nitrokey device. The emulated device should work as if a real device was plugged-in to the host.

Tasks Involved:

• 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.

Priority: Low

Difficulty: High

Relevant Knowledge: C, embedded programming

Description: FIDO is a "hot" standard for strong authentication in the web based on USB devices. Technically this involves signatures and a challenge-response protocol. During this project an enhancement to the U2F specification should be proposed which would enable en/decryption for JavaScript applications. This proposal should be implemented in a proof-of-concept based on given reference code.

Tasks Involved:

• Research the given FIDO2 specification and previous related discussion (e.g. in W3C working groups)
• Design a solution and agree with mentor
• Patch a given FIDO implementation of a virtual dongle
• Patch a given browser support or provide browser add-on
• Provide simple JavaScript test application to demonstrate its usage

Expected results: Patched reference code and demo JavaScript application to demonstrate the usage.

Recommendation: This is for students with strong architectural and abstract thinking.

Priority: Medium

Difficulty: High

Relevant Knowledge: protocols, JavaScript, Cryptography

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.

Tasks Involved:

• 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
• test

Expected results: A fully working server implementation. A policy for key handling.

Recommendation: This is for students with strong security and cryptography focus.

Priority: Low

Difficulty: Medium

Relevant Knowledge: Cryptography, Web programming, preferred: Ocaml

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.

Resources:

• Google's OSS-Fuzz
• american fuzzy lop