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.

Firmware Enhancements

P { margin-bottom: 0.21cm; }A:link { }

The project ideas in this section require skills in embedded programming.

H3 { margin-bottom: 0.21cm; }H3.ctl { font-family: "Lohit Hindi"; }P { margin-bottom: 0.21cm; }A:link { }

One Time Password Optimization

Description: The current One Time Password (OTP) implementation doesn't encrypt the secrets in the Crypto Stick. (Earlier it was planned to trigger the OTP with a dedicated button only). Now the firmware should be improved so that the secrets are encrypted with the embedded smart card. In addition, mechanisms to prevent the creation of large amounts of tokens should be prevented.The challenge-responds version of OTP called OCRA should be implemented.

Tasks Involved:

Integrate the smart card to encrypt and decrypt the OTP secrets
Add throttling mechanisms

Add OCRA feature to OTP
Update the client tool to support OCRA, potentially create a FireFox addon for this purpose
Test

Priority: High

Support for Google's U2F (FIDO Alliance)

Description: Implement support for the FIDO Alliance's U2F token.

Tasks Involved:

Get familiar with the U2F specification
Draft an approach to integrate U2F to the Crypto Stick
Implement U2F to the firmware
Implement U2F support into the Crypto Stick Tool
Test
See this reference code

Priority: High

Links: 1, 2, 3, 4, 5

L4-Based Secure eCash Server

OpenCoin is a related open source project to build an anonymous digital cash system. L4 is a microkernel for secure embedded environments. This project is to implement a secure server for OpenCoin based on L4re. The server would perform the following activities: receive a token, verify its integrity, create a new token, sign it by calling a HSM, store the old token in an external DB, send back the new token.

Tasks Involved:

Get familiar with the OpenCoin protocol and L4re.
Agree the architecture with mentor
Implement the external interfaces
Implement JSON parsing and token structures etc.
Implement SHA2 hashing and RSA signature validation, preferrable by utilizing existing libraries.
Port and integrate existing PKCS#11 driver to L4re
Documentation, testing

Priority: High

OpenPGP JavaCard

Re-implement the OpenPGP Card specification on a JavaCard device. A project space has already been setup here but this implementation seems to be more mature.

Priority: High

H3 { margin-bottom: 0.21cm; }H3.ctl { font-family: "Lohit Hindi"; }P { margin-bottom: 0.21cm; }A:link { }

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. Crypto Stick would be shipped with the public signing key. User downloads a signed firmware update for their device, and loads it onto the Crypto Stick. Crypto Stick 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 Crypto Stick 1.4 or for the new Crypto Stick 2 which is Atmel AT43UC-based.

Tasks Involved:

Get familiar with Crypto Stick's firmware.
Decide for a bootloader to use
Get the bootloader running
Integrate hash- and RSA signature verification functions
Implement load-firmware function
If necessary: write client tool to send new firmware to Crypto Stick
Test

Priority: Medium

Links: 1, 2, 3, 4,5

H3 { margin-bottom: 0.21cm; }H3.ctl { font-family: "Lohit Hindi"; }P { margin-bottom: 0.21cm; }A:link { }

One Time Passwords for GNUK

Description: Migrate the existing One Time Password (OTP) feature to GNUK. OTP is a two-factor authentication mechanism which has got some traction recently. It works with Gmail, Google Apps, Facebook, Dropbox, AWS and more. We implemented OTP on the Crypto Stick's firmware during GSOC 2012. Now we are planning to port this feature to GNUK firmware as well. You can think of GNUK as a "Crypto Stick light". Both systems are STM32 based.

Tasks Involved:

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

Priority: High

OpenCoin Wallet

Description: Similar to BitCoin wallet, build a hardware wallet for OpenCoin's digital cash system.

Tasks Involved:

Plan the architecture
Discuss and agree on an approach with mentor
Implement in firmware
Implement in client tool
Test

Priority: Medium

OpenPGP firmware

Description: Currently the Crypto Stick is simply a secure key storage and all OpenPGP/X.509-related operations are performed outside (e.g. by GnuPG). Instead of this approach it should be evaluated how more X.509 and OpenPGP specific functionality could be integrated into the firmware. This should enable to use the Crypto Stick on any computer without the need for specific applications. One obvious approach could be GPGMe. Other OpenPGP frameworks exist but aren't maintained anymore. The target platform would be Crypto Stick 2 which is based on FreeRTOS.

Tasks Involved:

Evaluate which existing software and libraries could be ported to the Crypto Stick firmware. Note that no Linux and libc is available in the firmware, so dependencies are an important aspect.
Port the selected firmware to the Crypto Stick
Implement an interface to use the library. E.g. a file interface to decrypt or sign files automatically in the OpenPGP format.
Test

Priority: Low

BitCoin Wallet

Description: Add BitCoin Wallet feature to Crypto Stick. The easier option is to enhance an existing BitCoin Wallet software with a smart card extension. The smart card should be used to encrypt the wallet file (which is stored on the PC's harddisk). Alternatively, the more complex approach would be to implement a modified firmware which would (still) interact with a Wallet software on the PC but which would perform the transactions on the Crypto Stick. This would implicate the question if a display and keys should be included or not. More details. Trezor is a similar project and a first step would be to find out their status and architecture.

Tasks Involved:

Evaluate Trezor and other potential architectures
Discuss and agree on an approach with mentor
Implement in firmware
If required: Update client tool accordingly
Test

Priority: Low

Application Integration

H3 { margin-bottom: 0.21cm; }H3.ctl { font-family: "Lohit Hindi"; }P { margin-bottom: 0.21cm; }A:link { }

GUI Optimization

Description: The Crypto Stick Tool allows administrating and using the Crypto Stick. It's based on QT4 and runs on Linux, Windows and MacOS. The GUI looks odd and should be improved to look good and to provide a super-easy user experience. Also the GUI should be updated to QT5 and be (potentially modified) and compiled for Android. As a starting point you may want to take a look to the existing tickets, the ones assigned to the UI.

Tasks Involved:

Update from QT4 to QT5
Plan how to improve the user experience
Adding a "wizard" mode to initialize the device
Optimize GUI
Compile and test for Android
Potentially: Modify for Android
Test

Priority: High

OpenPGPjs 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 Crypto Stick. 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 text - in particular e-mails - 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. Significant work has already been provided.
Tasks involved:

Get familiar with OpenPGPjs and the patch
Update 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

Priority: High

OpenCoin Digital Cash App

OpenCoin is a true digital cash system, similar to the former DigiCash/eCash based on tokens and providing real anonymity. A prototype wallet app is already available and has been written in JavaScript. Project scope is to implement a mature wallet with additional features (e.g. p2p transactions, encrypted wallet, QR codes), better look and feel and plattform independent (e.g. C, JavaScript+PhoneGap)

Tasks Involved:

Make yourself familiar with the OpenCoin protocol
Agree the feature set
Develop and test the wallet

Priority: High

Firefox Add-On

Description: Make the usage of OTP easier by creating a Firefox Add-On which "links" the Crypto Stick's OTP functionality to the web browser.

Tasks Involved:

Get familiar with FirefoxAddons, OTP, and the Crypto Stick Tool
Draft the features of and way the FireFox Addon should work
Implement and test the AddOn

Priority: Medium

True Crypt improvement

Description: True Crypt already has the capability to use smart cards (via PKCS#11) to unlock encrypted volumes. However, this feature is suboptimal (from a security standpoint) and need to be improved. Currently TrueCrypt simply stores the so called keyfile in the (PIN protected) Crypto Stick (or other smart card). Instead TrueCrypt should use the expected challenge-response mechanism of smart cards: The volume key (AFAIK called "master key") should be encrypted with smart card's certificate/key and stored at the volume. In order to unlock an encrypted volume, TrueCrypt should send the encrypted volume key to the smart card and receive the unencrypted key back. The unencrypted key should never be stored anywhere. A user documentation incl. screen shots should be created.

Tasks Involved:

Understand PKCS#11 interface and TrueCrypt's internals. You can see how PKCS#11 interface is implemented in OpenSC. This guy is author of pkcs#11 implementation in many application. I think TrueCrypt has implemented a part of pkcs#11 already (to store keyfile to smartcard)
Develop solution and agree with TrueCrypt's developers.
Patch and test TrueCrypt with Crypto Stick.
Commit patch to TrueCrypt and incorporate potential feedback from developers.
Publish fork of TrueCrypt including binaries
Create user documentation.

Priority: Medium

KeePass Plugin

KeePass is a great password manager. A plugin is available for Windows and KeePass 2.x which allows to protect encrypted password storages/files with the Crypto Stick. The goal would be to port the plugin to Linux and Mac OS so that it works with the appropriate KeePass port. This library seems to be a perfect fit.
Tasks involved:

Evaluate existing plugins and the KeePass ports' plugin interface.
Design solution to utilize as much as possible of the existing plugin and KeePass ports.
Port the Plugin and publish binaries
Create user documentation incl. screen shots.

Priority: Medium

Password Safe integration

Password Safe is a password manager. It needs to be checked which plugins already exist in order to use Password Safe with the Crypto Stick (e.g. PKCS#11 plugin). Potentially a plugin should be developed which allows to protect encrypted password storages/files with the Crypto Stick. The plugin should work for all OS supported by Password Safe. The developed feature should be generic and base on PKCS#11 in order to allow protection by other smart cards as well (not only Crypto Stick). A user documentation incl. screen shots should be created. Here and here are some similar applications which demonstrate how it could look like.
Tasks involved:

Evaluate existing plugins and Password Safe's plugin interface.
Design solution in particular decide whether to patch existing plugin or develop a new plugin from scratch.
Implement and test plugin.
Create user documentation incl. screen shots.

Priority: Low

Linux LUKS integration

LUKS is a file system encryption solution for Linux. It should be enhanced so that it can be unlocked with the Crypto Stick. An important aspect is, that for full-disk encryption the Crypto Stick 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.

Priority: Medium

Android Integration

Integration with Android platform for data and password encryption and authentication. This is an "early stage idea" and we haven't researched it very much. This and that links may be a starting point. The key questions would be what needs to be done for apps on Android to access the Crypto Stick? Ideally without rooting the ROM. Which apps' support would be most useful? Also the Guardian Project may have some thoughts about this topic.

Priority: Medium

PKCS#11 Cluster

Simple PKCS#11 wrapper which schedules work among several Crypto Sticks (or other PKCS#11 smart cards).

Purpose: To distribute signing/encryption tasks on a high-load server among several Crypto Sticks efficiently without requiring a modification of the application. The wrapper should in fact be a PKCS11 module itself so that it can be loaded by any application which supports PKCS11.

structure: Application (e.g. Apache) <-> this PKCS11 wrapper <=> several PKCS11 Crypto Stick driver (OpenSC) <=> several Crypto Stick devices (hardware)

Functionality: At startup all available Crypto Sticks 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 PKCS11 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 Crypto Sticks, 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 PKCS11 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 Crypto Stick 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 PKCS11 Helper might be the right tool to integrate this feature. It should be assumed that all Crypto Sticks are equipped with identical keys and passwords.
Optional:

Init parameter: path to load any PKCS11 driver. Rather than Crypto Stick 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

Priority: Medium

Integrate with Mozilla Persona

Integration with Mozilla's Persona project. See details.

Priority: Low

Integration with Firefox password manager

= Description to be added =

Priority: Low

Miscellaneous

Customize a Secure Linux Distribution

A secure Linux distribution should be customized to boot from the Crypto Stick Storage. The distribution of choice should focus on security applications. It should be customized in a way that the boot partition is located on the Crypto Stick Storage's unencrypted (and configurably read-only) volume. When its booted, the user should be prompted to enter his/her password. This password is used to unlock the encrypted volume which contains the rest of the distribution. Any user data or configuration changes are stored on the second volume.

This task involves writing a tool which at a very early stage of the boot process, displays a password prompt. The tool communicates with the Crypto Stick over its HID interface to provide the password and unlock the volume. Please research about "Linux full disk encryption" to get an idea about similar tools to learn from.

The tool should be prepared to be included into most popular Linux distributions quite easily.

Also we need a solution if the boot system on the read-only volume is going to be updated with patches. Maybe the user should be prompted to remove the read-only lock first.

Documentation Improvement

Improve documentation how to use the Crypto Stick. A challenge is that the Crypto Stick can be used for various use cases and with a diverse range of applications. For instance the way how to setup the Crypto Stick and applications is different if a user wants to use OpenPGP-based email encryption to a setup for X.509-based web-login. Hence, which is the default way to initialize a Crypto Stick?

Goal:

1) To develop a structure for the documentation which fits all purposes. New users should be guided easily how to setup the Crypto Stick and their applications. At the same time all applicable use cases should be covered. The structure might become a logical tree structure where user can choose next steps depending on their use case. Also it should be considered to have clickable section headings as in the documentation of Github.

2) To be documented: The setup with Linux, Windows, MacOS X and with the Windows MiniDriver in particular. User authentication for these operating systems. The setup and usage with various applications. This may include GnuPG, GPA, OpenSC, Thunderbird and Enigmail, Thunderbird's X.509 email encryption, Firefox authentication, TrueCrypt, OpenSSH, OpenSSL, PuTTY/KiTTY, MS Outlook. Usage with web services such as OpenID providers, Gmail, Dropbox, etc.

Where good documentation exists in the web, this should be linked. Otherwise documentation would need to be created (including screenshots) into Drupal CMS. Selected use cases should be documented in video. You may take a look to the Yubico website to get some inspirations. But keep in mind that their product has only one feature and one use case so its much easier to structure the website.

A Crypto Stick which is capable to perform mass storage encryption and OTP would be provided. The usage of these features should be documented in addition to the core smart card feature. Ideas for a better layout of the website would be welcome.

First steps: 1) Develop a structure 2) Identify to be documented applications 3) Get familiar with the Crypto Stick, Drupal, screenshot and screencast tools 4) Start documenting

Priority: High

NFC Interface

Add a NFC interface so that the Crypto Stick can be used with a mobile phone.

Tasks Involved:

Plan technology and solution
Purchase or build test system
Add feature to firmware
Integrate NFC interface to minimal-size Crypto Stick

Priority: Medium

Crypto Stick 3 study

Crypto Stick 3 is just in an early idea stage but key focus would be a high performance. Several potential and powerful CPUs exists and SOCs are a promising approach. But many of them are way too complex and of large size which is not required for our purpose. Preferably, the firmware shouldn't be based on Linux (which would be to complex either) but be based on FreeRTOS instead. The goal would be to research the CPUs available and select appropriate ones for CS3. This should include a performance and cost analysis. An idea is to use a FPGA (e.g. this). Then a first proof-of-concept could be implemented.

Tasks Involved:

Develop evaluation criteria
Evaluate CPUs available on the market
Decide for a specific CPU
Purchase development board
Implement proof of concept demonstrating the performance
Test

Priority: Low