OpenPGP Card is an ISO/IEC 7816-4 compatible smartcard that is integrated with many OpenPGP functions, including signature, encryption, and authentication. It provides an trustful computing environment isolated from the host computer, to guard one's private keys from attacks and exposures. ZetiControl in Germany is the first manufacturer of OpenPGP Card based on BasicCard platform. Since then, compatible USB tokens have also been manufactured, such as Yubikey and Nitrokey.
Currently for compatible USB tokens, there are two approaches of OpenPGP Card implementation:
- Based on secure hardware.
- The hardware is usually temper-proof to some extents, but the system is usually proprietary with mandatory NDA required, such as Yubikey.
- Based on generic microcontroller, with gnuk firmware developed by Niibe Yutaka.
- It allows 100% free hardware design and software, but the chip is not hardened for security thus vulnerable to physical attacks.
In other words, the user is forced to choose between security and transparency.
But thanks to the IoT hype, many NDA-free and regulation-free "secure elements" for cryptograpic key storage have entered the market. This project is going to perform early experiments with a ATECC508A chip by Atmel, and see if it is possible to integrate it to the gnuk USB token to improve the physical security, allowing users to secure their private data with GnuPG with a high degree of physical security.
Looking for hackers with the skills:
gnupg gpg pgp security cryptography embedded arm microcontroller stm32 atmega
This project is part of:
Hack Week 17
Activity
Comments
Similar Projects
Migrate from Docker to Podman by tjyrinki_suse
Description
I'd like to continue my former work on containerization of several domains on a single server by changing from Docker containers to Podman containers. That will need an OS upgrade as well as Podman is not available in that old server version.
Goals
- Update OS.
- Migrate from Docker to Podman.
- Keep everything functional, including the existing "meanwhile done" additional Docker container that is actually being used already.
- Keep everything at least as secure as currently. One of the reasons of having the containers is to isolate risks related to services open to public Internet.
- Try to enable the Podman use in production.
- At minimum, learn about all of these topics.
- Optionally, improve Ansible side of things as well...
Resources
A search engine is one's friend. Migrating from Docker to Podman, and from docker-compose to podman-compose.
VulnHeap by r1chard-lyu
Description
The VulnHeap project is dedicated to the in-depth analysis and exploitation of vulnerabilities within heap memory management. It focuses on understanding the intricate workflow of heap allocation, chunk structures, and bin management, which are essential to identifying and mitigating security risks.
Goals
- Familiarize with heap
- Heap workflow
- Chunk and bin structure
- Vulnerabilities
- Vulnerability
- Use after free (UAF)
- Heap overflow
- Double free
- Use Docker to create a vulnerable environment and apply techniques to exploit it
Resources
- https://heap-exploitation.dhavalkapil.com/divingintoglibc_heap
- https://raw.githubusercontent.com/cloudburst/libheap/master/heap.png
- https://github.com/shellphish/how2heap?tab=readme-ov-file
Contributing to Linux Kernel security by pperego
Description
A couple of weeks ago, I found this blog post by Gustavo Silva, a Linux Kernel contributor.
I always strived to start again into hacking the Linux Kernel, so I asked Coverity scan dashboard access and I want to contribute to Linux Kernel by fixing some minor issues.
I want also to create a Linux Kernel fuzzing lab using qemu and syzkaller
Goals
- Fix at least 2 security bugs
- Create the fuzzing lab and having it running
The story so far
- Day 1: setting up a virtual machine for kernel development using Tumbleweed. Reading a lot of documentation, taking confidence with Coverity dashboard and with procedures to submit a kernel patch
- Day 2: I read really a lot of documentation and I triaged some findings on Coverity SAST dashboard. I have to confirm that SAST tool are great false positives generator, even for low hanging fruits.
- Day 3: Working on trivial changes after I read this blog post:
https://www.toblux.com/posts/2024/02/linux-kernel-patches.html. I have to take confidence
with the patch preparation and submit process yet.
- First trivial patch sent: using strtruefalse() macro instead of hard-coded strings in a staging driver for a lcd display
- Fix for a dereference before null check issue discovered by Coverity (CID 1601566) https://scan7.scan.coverity.com/#/project-view/52110/11354?selectedIssue=1601566
- Day 4: Triaging more issues found by Coverity.
- The patch for CID 1601566 was refused. The check against the NULL pointer was pointless so I prepared a version 2 of the patch removing the check.
- Fixed another dereference before NULL check in iwlmvmparsewowlaninfo_notif() routine (CID 1601547). This one was already submitted by another kernel hacker :(
- Day 5: Wrapping up. I had to do some minor rework on patch for CID 1601566. I found a stalker bothering me in private emails and people I interacted with me, advised he is a well known bothering person. Markus Elfring for the record.
Wrapping up: being back doing kernel hacking is amazing and I don't want to stop it. My battery pack is completely drained but changing the scope gave me a great twist and I really want to feel this energy not doing a single task for months.
I failed in setting up a fuzzing lab but I was too optimistic for the patch submission process.
The patches
Bot to identify reserved data leak in local files or when publishing on remote repository by mdati
Description
Scope here is to prevent reserved data or generally "unwanted", to be pushed and saved on a public repository, i.e. on Github, causing disclosure or leaking of reserved informations.
The above definition of reserved or "unwanted" may vary, depending on the context: sometime secret keys or password are stored in data or configuration files or hardcoded in source code and depending on the scope of the archive or the level of security, it can be either wanted, permitted or not at all.
As main target here, secrets will be registration keys or passwords, to be detected and managed locally or in a C.I. pipeline.
Goals
Detection:
- Local detection: detect secret words present in local files;
- Remote detection: detect secrets in files, in pipelines, going to be transferred on a remote repository, i.e. via
git push;
Reporting:
- report the result of detection on stderr and/or log files, noticed excluding the secret values.
Acton:
- Manage the detection, by either deleting or masking the impacted code or deleting/moving the file itself or simply notify it.
Resources
- Project repository, published on Github (link): m-dati/hkwk24;
- Reference folder: hkwk24/chksecret;
- First pull request (link): PR#1;
- Second PR, for improvements: PR#2;
- README.md and TESTS.md documentation files available in the repo root;
- Test subproject repository, for testing CI on push [TBD].
Notes
We use here some examples of secret words, that still can be improved.
The various patterns to match desired reserved words are written in a separated module, to be on demand updated or customized.
[Legend: TBD = to be done]
Model checking the BPF verifier by shunghsiyu
Project Description
BPF verifier plays a crucial role in securing the system (though less so now that unprivileged BPF is disabled by default in both upstream and SLES), and bugs in the verifier has lead to privilege escalation vulnerabilities in the past (e.g. CVE-2021-3490).
One way to check whether the verifer has bugs to use model checking (a formal verification technique), in other words, build a abstract model of how the verifier operates, and then see if certain condition can occur (e.g. incorrect calculation during value tracking of registers) by giving both the model and condition to a solver.
For the solver I will be using the Z3 SMT solver to do the checking since it provide a Python binding that's relatively easy to use.
Goal for this Hackweek
Learn how to use the Z3 Python binding (i.e. Z3Py) to build a model of (part of) the BPF verifier, probably the part that's related to value tracking using tristate numbers (aka tnum), and then check that the algorithm work as intended.
Resources
- Formal Methods for the Informal Engineer: Tutorial #1 - The Z3 Theorem Prover and its accompanying notebook is a great introduction into Z3
- Has a section specifically on model checking
- Software Verification and Analysis Using Z3 a great example of using Z3 for model checking
- Sound, Precise, and Fast Abstract Interpretation with Tristate Numbers - existing work that use formal verification to prove that the multiplication helper used for value tracking work as intended
- [PATCH v5 net-next 00/12] bpf: rewrite value tracking in verifier - initial patch set that adds tristate number to the verifier
SUSE Prague claw machine by anstalker
Project Description
The idea is to build a claw machine similar to e.g. this one:
Why? Well, it could be a lot of fun!
But also it's a great way to dispense SUSE and openSUSE merch like little Geekos at events like conferences, career fairs and open house events.
Goal for this Hackweek
Build an arcade claw machine.
Resources
In French, an article about why you always lose in claw machine games:
We're looking for handy/crafty people in the Prague office:
- woodworking XP or equipment
- arduino/raspi embedded programming knowledge
- Anthony can find a budget for going to GM and buying servos and such ;)
Grapesss: a physical Shamir's Secret Sharing application [ESP32-C3 + Mobile] by ecandino
Description
A couple of years ago I created StegoSecretS, a small cli used to encrypt and split a secret into multiple keys, using the Shamir's Secret Sharing algorithm.
The idea is to re-implement the project using physical devices. One device alone will be useless, but when close together they can be used to decrypt the secret.
On a practical side the user encrypts the secret with a mobile application. The same application is used to split the secret, and load the partial keys into different micro-controllers. Another user will be able to decrypt the secret only having at least N devices close together (using the application).
I'm planning to use a couple of ESP32-C3 I bought, and build a very simple Android mobile application.
Goals
- Learn about Rust and micro-controllers (ESP32-C3)
- Learn about mobile applications (Android and Kotlin)
Resources