Ideas

jans23 edited this page Feb 27, 2017 · 39 revisions

This is a collection of ideas for Google Summer of Code. Alternatively you are welcome to submit your own ideas. Please refer to the Getting Started page and discuss your plans at our development mailinglist.

Overview

Firmware Enhancements

Application and Integration

Miscellaneous

Firmware Enhancements

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

Tasks Involved:

  • Get familiar with JavaCard platform and development environment
  • Research existing JavaCard apps (mostly on Github)
  • Build existing apps 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.

Priority: High

Difficulty: High

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. It needs to be based on and be integrated to the given firmware. Good documentation and mature client software is available for testing.

Links: 1, 2, 3, 4

Tasks Involved:

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

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.

Tasks Involved:

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

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.

Priority: Medium

Difficulty: Medium

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

Details:

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

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, assembla, 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.

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

OpenCoin Wallet

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.

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

Priority: Medium

Difficulty: High

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.

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

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.

Tasks Involved:

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

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:

  • 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

GUI and UX Optimization

Description: The Nitrokey App allows administrating and using the Nitrokey. It's based on QT5 and runs on Linux, Windows and MacOS. The App looks a bit odd and should be improved to a perfect look and to provide a super-easy user experience (UX). As a starting point you may want to take a look to the existing tickets, the ones assigned to the UI.

Tasks Involved:

  • Plan how to improve the user experience; create mockups.
  • Add a "wizard" to initialize Nitrokey devices
  • Add a "wizard" to configure OTPs
  • Add small question mark icons next to each (OTP) setting, which displays a short explanation of the particular setting when the mouse is pointing or clicking on it.
  • 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.
  • Optimize GUI
  • Test

Expected results: An improved Nitrokey App with awesome look and feel.

Priority: High

Difficulty: Low

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.

Tasks Involved:

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

Priority: Medium

Difficulty: Medium

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.

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: Medium

Difficulty: Medium

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.

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: High

Difficulty: Medium

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.

Tasks Involved:

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

Priority: Medium

Difficulty: High

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

Mailvelope / OpenPGP.js Integration

Description: This project's goal is to update a patch for OpenPGPjs 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 you 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. Web2Native Bridge is another similar project.

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 Firfox 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

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.

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: Medium

Difficulty: High

Relevant Knowledge: C, Linux

Miscellaneous

PKCS#11 Cluster

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

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.

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

U2F Enhanced for End-to-End Crypto

Description: U2F 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 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
  • 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

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.

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