Other Tasks:
Robust SSH library
A robust library that provides full SSH capabilities (SSH-Tunnels, ...) that can be used in other applications, and the necessary wrappers for common languages like PHP, Perl, ...
ELF Signing and ELF-Loader-Signature Verifying
We would like to have X.509 and/or OpenPGP based ELF signing tools and improved ELF-Loaders that can enforce signature verification on load. There are several projects that are working on it, but none seems to be complete yet: http://wiki.cacert.org/wiki/CodesigningCert#head-6bbdb82bb3228b4a676f589f48b9c0e1d1fefff2
Contact for this task: [email protected]
- Working on it:
- Comments:
- Could be interesting to handle validation in userspace and mark validated executables as 'safe' until notified of modification. (samj)
- Yes, caching the validation in a secure way might be helpful for lower-security demands. Higher security demands might want to turn caching off, though.
Secure Compression
We are seaching for a compression system (library, ...) which does not contain any checksums, avoids any recognizable structures in the compressed file as far as possible, and where every file is a valid compressed file that can be decompressed correctly. The compression factor should be similar or better than ZIP, but must not be better than ~ 1:100, even with extremely low entropy files.
Contact for this task: [email protected]
- Working on it:
- Comments:
Depending on application, existing compression & truecrypt or similar could be an option. (samj)
- No, we specifically do not want to use encryption functions to replace compression function. We specifically want a compression function.
- Question: Do you expect decompressing any file and recompressing the result will yield the original file (otherwise you would know that your original file has not been compressed by this library before)? That will make a solution a lot harder. My intuition says it is impossible (or, in other words, it will only work in the trivial case when the compressed files are always the same size as the uncompressed ones, in which case it is no compression but an encryption), but as I fail to prove it mathematically, I might be wrong. Especially if the file may only grow by less than one percent in the worst case (as it is with ZIP).
Answer: No, I would say that we do not need that a decompression and recompression has to yield the original file. And there is one system that prooves that it is not impossible: The so called NULL compression. The NULL compression yields the original file
Firefox Extension for HashServer
We would like to have a Firefox Extension that extracts the public key from each certificate Firefox processes, calculates the SHA-1 sum of it, and looks it up in a blacklist that is regularly updated from http://hashserver.cacert.org/ In case a compromised key is found, the user is alerted.
Contact for this task: [email protected]
Working on it: [email protected] (G-Lex)
See also ...
OtherTasks (this page)
LUKS Security
Find a solution to tell LUKS/DM-Crypt in case of emergency to wipe all the keys in memory, block disk access, and ask for the passwords on the console again. Perhaps a /proc file interface like /proc/sys/dmcrypt/emergency would be helpful.
Contact for this task: [email protected]
- Working on it:
- Comments:
- Since a script will likely be talking to /proc, why no do this in a script to start with. Good idea nonetheless. (samj)
- How can a script wipe the keys inside the kernel? With /dev/mem or /dev/kmem ?
Assumption was that the tools themselves (eg for unmounting) would do this but they could fail... you basically want a forced umount which prefers confidentiality over integrity. Hook that to an internal (USB?) accelerometer, a photodiode, case intrusion switch and a microphone for good measure and you'd make life *very* difficult for an attacker
(samj) - Unmounting isn't a good option, since it breaks running applications. Instead of unmounting, it should wipe the keys in memory and block all disc accesses until the password is entered again. That way the applications do not need to crash.
LUKS Robustness
Currently LUKS is usually using hardcoded devicenames, which causes a problem when race-conditions result in randomly different devicenames upon booting (/dev/sda <-> /dev/sdi). In those cases LUKS doesn't find the encrypted harddisk anymore, and can't boot. Find a solution that LUKS does not depend on the hardcoded values anymore (perhaps still use them as default for the first try, but the encrypted partition isn't found there, then fall back to search for it on all other available devices) The solution should be then incorporated into Debian and Ubuntu (which are both affected by that problem)
Contact for this task: [email protected]
- Working on it:
Doesn't help Debian/Ubunu(?) but I've got this on mine (Daniel) - probably a recent udev version
/dev/disk/by-id/ata-ST3250620AS_6QE0M5E0-part3 /dev/disk/by-id/scsi-SATA_ST3250620AS_6QE0M5E0-part3 /dev/disk/by-id/ata-ST3250620AS_6QE0M5E0-part2 /dev/disk/by-id/scsi-SATA_ST3250620AS_6QE0M5E0-part2 /dev/disk/by-id/ata-ST3250620AS_6QE0M5E0-part1 /dev/disk/by-id/scsi-SATA_ST3250620AS_6QE0M5E0-part1 /dev/disk/by-id/ata-ST3250620AS_6QE0M5E0-part4 /dev/disk/by-id/scsi-SATA_ST3250620AS_6QE0M5E0-part4 /dev/disk/by-id/ata-ST3250620AS_6QE0M5E0 /dev/disk/by-id/scsi-SATA_ST3250620AS_6QE0M5E0
Secure VPN
We are searching for a vendor that is able to deliver a secured Point-to-Point VPN solution that is designed for high-security environments. We are interested in 2-4 VPN boxes, with the following requirements: Strong casing, hardened TCP/IP stack, double encryption, no web-frontend, no IPSEC, independent security reviews (sourcecode availability preferred). Layer 2 bridging availability would be great. Must not allow internet access for any of the 2 networks that are connected through the VPN. It would be preferred to have the VPN in a Network-HSM style casing. A potential product: http://www.flexsecure.de/ojava/tunnelbox.html
Contact for this task: [email protected]
- Working on it:
Full Disk Encryption for OpenBSD
We could need a full disk encryption system for OpenBSD, preferably integrated into the installation process like Debian/Ubuntu Installer does it.
Contact for this task: [email protected]
- Working on it: