Chaos Computer Club - archive feed

Automotive hacking hasn't started with Miller/Valasek in 2015 - and it hasn't ended with it, either. This talk will give an overview of automotive insecurities of the past ~10 years, a brief history of some kind. I will also provide an outlook on what the future on four wheels might hold, security-wise.

This talk will give an exhaustive overview of all the automotive hacks in the past 10 years, and analyze the technical issues and vulnerabilities that have been exploited. Ranging from the automotive hacking papers in the early 2010-ies by US researchers, towards the infamous Miller/Valasek presentations starting 2015, the magic work of KeenLabs and 360 Group, and covering comma.ai, the different Tesla hacks, entry system relay attacks and the recent ADAC study, towards AI-confusion attacks. I will try to analyze the underlying vulnerabilities, how they can be (respectively are already) prevented in modern vehicles, and what the future holds.

about this event: https://program.mch2022.org/mch2022/talk/TVYLPH/

Payment Service Directive (PSD2) is a fairly recent directive in Europe when it comes to electronic payments. For most of us this has happened invisibly. Although this new directive creates a lot of opportunities for fintech companies it also puts the privacy of tenths of millions of people in the hands of private companies. This talk will discuss the opportunities this will provide within Europe both for Fintech's... and scammers.

In 2020 the Payment Service Directive 2 (PSD2) has become the directive governing banking in Europe. This means that for financial transactions between businesses, persons and banks a new European-wide payment system is available.

While before PSD2 in order to be able to act as a Payment Service Provider (PSP) you needed to be certified by the local central bank, now with PSD2 this is no longer necessary. This means all transaction data for an IBAN number going back up to years can be queried by commercial parties investing a few hundred euro’s. An example will be shown how easy it is to overlook giving consent for this data exchange and how to revoke this consent.

This talk will discuss the opportunities this new directive will provide EU residents, but will also show what implications this has in terms of privacy and how it enables scammers to automate scams.

about this event: https://program.mch2022.org/mch2022/talk/MDKSB9/

Why do we believe in fake news? What are news siloes? Why can't we seemingly find a solution to discussions like blackface or the corona-deniers How to break your bubble. This lecture discusses the psychological reasons as seen from the perspective of a social engineer.

Why do we believe in fake news? What are news siloes? How to break your bubble.

-

-

about this event: https://program.mch2022.org/mch2022/talk/VLVBVG/

Electric vehicles present a real opportunity to take a step towards better designed, more reliable, and sustainable transport. Instead, electric cars have become nightmarishly complex gadgets whose limited lifespans will make them less sustainable than a diesel pickuptruck running on whale oil. This talk will explore the problem, and make a few suggestions as to what could be done about it.

I want my next car to have an electric motor, I want it to push the boundaries of what is capable with a battery and I want it to be an automotive tour de force that represents a real advance over my gasoline car in terms of lifetime sustainability. The switch to electric cars represents an opportunity like no other to deliver a new type of car that doesn’t carry the baggage of what has gone before, but what I see in the electric cars available to me just doesn't live up to that dream. The car industry now makes cars that don't rust and don't wear out, so for planned obsolescence they now rely on technological complexity to ensure they reach the scrap heap long before their promise of true sustainability can be realised. This talk will attempt to deconstruct the problem, and look at how it might be remedied.

about this event: https://program.mch2022.org/mch2022/talk/M3D7UA/

Go is often thought of as a server programming language, especially one used for microservices. However, I argue that it can also be a good language for much smaller systems: microcontrollers. Especially with the Internet of Things there is a need for a language that is safer, easier to use (harder to misuse) and easier to build and test.

For many years, C has been the dominant language in the embedded world and especially microcontrollers. Almost all embedded systems are written in C. The last few years this has been changing, with new languages being used for this purpose:

* [Rust](https://www.rust-lang.org/what/embedded) has seen rapid growth in embedded systems with its focus on safety and expressiveness. It is in fact a great replacement for C, as it is just as low level and efficient as C but without all the footguns. However, many people find this language hard to learn.

* Another language that's sometimes used is Python, in the form of [MicroPython](https://micropython.org/). This is in fact what powers the SHA2017 and MCH2022 badges. While the project is an amazing accomplishment, it still suffers from the fact that the language is interpreted and there are limits to how fast it can be.

* Some people have also used other languages, such as [Lua](https://nodemcu.readthedocs.io/en/release/), [JavaScript](https://www.espruino.com/), [Oberon](https://www.astrobe.com/), [Forth](https://hackaday.com/2017/01/27/forth-the-hackers-language/), [Ada](https://blog.adacore.com/ada-on-the-microbit), and probably others. I'm not aware of a language that got much further than experimental or very specific uses.

* Then there is [TinyGo](https://tinygo.org/), which is a new compiler for the Go language and primarily targets baremetal embedded systems and WebAssembly. This is what I will talk about.

TinyGo is a new compiler for the Go programming language. Its goal is to implement the Go language specification, be able to compile most of the Go standard library, but still optimize well enough so that binaries can run on a range of large and small embedded systems. It optimizes much more aggressively than the main Go implementation and the resulting binaries are able to run on systems ranging from the Arduino Uno, to the BBC micro:bit, to the MCH2022 badge with an ESP32 chip. I believe TinyGo offers most of the ease-of-use benefits of interpreted languages while providing most of the performance benefits of languages such as C.

In this talk, I will cover what kinds of problems C can cause, why Go can be a great fit on embedded systems, an explanation of some optimizations that it does that help lower its code size and RAM consumption, and some examples of projects written using TinyGo. Oh, and of course some demos.

about this event: https://program.mch2022.org/mch2022/talk/MNE98G/

Yes, this talk is about running your own mainframe on your own hardware. Mainframes are old, yes, but they are still very much alive. New hardware is still being developed and there are a lot of fresh jobs in this area too. A lot of mainframes run COBOL workloads. COBOL is far from a dead language. It processes an estimated 85% of all business transactions, and 5 billion lines of new COBOL code are written every year. In this session the speaker will help you in take your first steps towards running your own mainframe. If you like then after this session you can continue to build your knowledge of mainframe systems using the links provided during the talk. Come on in and learn the basics of a completely different computer system! And it will take you less than an hour to do that!

Yes, this talk is about running your own mainframe on your own hardware. Mainframes are old, yes, but they are still very much alive. New hardware is still being developed and there are a lot of fresh jobs in this area too. A lot of mainframes run COBOL workloads. COBOL is far from a dead language. It processes an estimated 85% of all business transactions, and 5 billion lines of new COBOL code are written every year. In this session the speaker will help you in take your first steps towards running your own mainframe. If you like then after this session you can continue to build your knowledge of mainframe systems using the links provided during the talk. Come on in and learn the basics of a completely different computer system! And it will take you less than an hour to do that!

about this event: https://program.mch2022.org/mch2022/talk/PBHJCP/

Nowadays, when a user wants to authenticate mostly centralized systems, such as DigiD in the Netherlands, are utilized. Extreme events can impact the reliability of such systems. Decentralized, and more privacy-preserving systems, such as [IRMA](https://irma.app/) can help to build more reliable authentication infrastructures. With IRMA, a user can store signed attributes, such as their full name or address, within the IRMA mobile app. Subsequently, the user can disclose a subset of her attributes to parties during an authentication session. The [Verifiable Credentials (VC)](https://www.w3.org/TR/vc-data-model/) standard helps to make such systems interoperable, that is, users can use attributes across different credential systems. With a proof of concept, we show how to make IRMA VC-compliant.

During extreme events, such as power outages or big floods, centralized systems are especially vulnerable as their availability can be impacted. This could result in that the whole system is unusable. Therefore, it is beneficial to develop decentralized infrastructures, as one is not dependent on centralized components.

Digital authentication nowadays is mostly done via centralized systems, such as DigiD, the authentication system of governmental services in the Netherlands. Every authentication session goes through a central authority, which makes the system centralized. Additionally, from a privacy-perspective, an issue is that such a system can keep track on which sites users authenticate. To achieve more system reliability and more user privacy, it is desirable to develop authentication systems that are working in a more decentralized manner.

One existing solution to this challenge is [IRMA](https://irma.app/). IRMA stands for I Reveal My Attributes and is developed by the Dutch non-profit organization [Privacy By Design](https://privacybydesign.foundation/). A central element of IRMA is a mobile app, which the foundation promotes as a digital passport on your own mobile device. Users can collect signed attributes, a set of attributes is called a credential, from authoritative parties. An attribute is for instance, your Dutch BSN, full name, or email address. IRMA protects the privacy of individuals by letting the individuals decide which attributes they want to disclose to whom, and by implementing advanced cryptography, including zero-knowledge proof techniques. Consequently, the receiving party can validate the authenticity of the disclosed credentials without the need to contact the party that issued the credentials.

[Verifiable Credentials (VC)](https://www.w3.org/TR/vc-data-model/) is a standard developed by the W3C. It provides a data model and a syntax aiming to make credential systems interoperable, for instance, it can enable users to disclose credentials issued by one system to another system.

Currently, IRMA can only be used within the IRMA ecosystem, that is, among servers and mobile apps that use the IRMA attributes. However, it would be desirable that people are able to use such advanced technologies and authentic attributes on the entire web across different systems. This avoids that people need different apps to be used, that could contain the same attributes, with different systems. Our research shows that it is possible to make IRMA VC-compliant via a proof of concept. Subsequently, through VCs, IRMA attributes are available for servers and apps outside the IRMA ecosystem. Similarly, other credentials can become universally verifiable.

As decentralized systems become increasingly more available, governments and other organizations can utilize reliable and privacy protecting authentication widely. This benefits everyone – even and especially during extreme events.

about this event: https://program.mch2022.org/mch2022/talk/3HTP8D/

Ankle monitors are devices typically used by law enforcement to track offenders, have you ever wondered how they work - which potential vulnerabilities they have or where to buy one ( or many )? This talk is about hacking electronic ankle monitors built by various Chinese manufacturers - and the protocols and software they use.

Ankle monitors are devices used by law enforcement to track offenders - typically ones on house arrest. They contain various sensors and GPS, WiFi, Cellular and sometimes RF communication to transmit data and determine their position.

This talk will go into detail for various brands on how they communicate with their servers - potential vulnerabilities and ways to escape/avoid detection. This talk concerns Chinese vendors of ankle monitors - but the processes are applicable to different brands and types as well. I will discuss how I developed a server which can be used with 4 vendors of these devices - and how I got the protocol documents for each of them through a bit of social engineering.

The focus will be on the technical details of how your location is determined - which fallbacks are used in case locating falls - and how data is communicated to the server - and the security implications of all of this. Some of devices are used by small nations to track for instance immigrants for COVID tracking - we will discuss the implications of this.

about this event: https://program.mch2022.org/mch2022/talk/DK3VKB/

TIC-80 fantasy console Byte Jam is a friendly competition to livecode a demo in a relaxed atmosphere. This can take an hour or more depending on the inspiration and time needed of the participants. You could follow the suggested random chosen topic or do your own thing.

TIC-80 fantasy console Byte Jam is a friendly competition to livecode a demo in a relaxed atmosphere. This can take an hour or more depending on the inspiration and time needed of the participants. You could follow the suggested random chosen topic or do your own thing.

TIC-80 is a fantasy console with limited resources like 240x136 pixels display, 16 color palette, 256 8x8 color sprites, 4 channel sound , etc. This gives the TIC-80 a very retro look and feel.

This byte jam is a good representation of the demoscene, where coders/hackers with very limited resources in hard or software make stunning audio and visual effects. In Europe the demoscene got status of cultural heritage in Finland, Germany and Polen and requested for Netherlands and other countries.

If you want to join this TIC-80 byte jam add you name to this wiki page : https://wiki.mch2022.org/Projects:Demoparty

about this event: https://program.mch2022.org/mch2022/talk/PG8QBM/

This is a rant about how moving ecosystems are not a good reason for centralizing a crucial service, how stickers are no substitute for a desktop client that does not crash, and how effectively shutting out less popular OS platforms is just not cool.

In his seminal work ["The ecosystem is moving"](https://signal.org/blog/the-ecosystem-is-moving/), Moxie Marlinspike laid out clearly the reasons why it's impossible to do what [Matrix](https://en.wikipedia.org/wiki/Matrix_(protocol)), or [the Fediverse](https://fediverse.party/), or for that matter the Web, have done: create a dynamic, quickly-evolving ecosystem without centralizing it.

For years, as a person responsible for information security of at-risk reporters and their sources, I have been advocating Signal as a secure Internet messaging service. And with good reasons.

Criticizing a security-sensitive tool like Signal is tricky, as it might be misconstrued as a call to abandon it, and move to alternatives that might be in fact worse. But here, at a hacker conference and with little risk of causing confusion and diverting users towards less secure platforms, can we please have an honest conversation about Signal's problems? And how 5 years after that blogpost, moxie's centralization has not solved them?..

There are good reasons to exert a level of control over what connects to a communication network. But effectively shutting out a community of developers that would love to implement Signal clients [for](https://gitlab.com/rubdos/whisperfish) [less](https://open-store.io/app/textsecure.nanuc) [popular](https://forum.pine64.org/showthread.php?tid=8505) [OSes](https://forums.puri.sm/t/how-can-you-install-signal-on-the-librem-5/10244) (many of which happen to attract the kind of infosec-aware crowd that used to be the core pushers of Signal) is not a good outcome.

Opening up more on the client side and providing some form of independent client development program (starting with a stable API) would already help a ton. Even if it's just the desktop client that gets re-written in something that is not in essence a packaged browser [trailing it's upstream on security patches](https://news.ycombinator.com/item?id=22239791).

Finally, we need to talk federation. Does it make moving fast and breaking things more difficult? Yes, yes it does, and that can be a good thing. It also makes the resulting federated service more resilient (one [service provider experiencing issues](https://www.indiatoday.in/technology/news/story/signal-users-globally-experiencing-issues-company-working-on-a-fix-1759524-2021-01-15) does not bring the whole network down). And, it lets others innovate without being locked out.

about this event: https://program.mch2022.org/mch2022/talk/7QRECD/