Profile cover photo
Profile photo
Johannes Zweng
Curious, interested in technology , open minded...
Curious, interested in technology , open minded...
About
Communities and Collections
View all
Posts

Post has attachment
Howto check EMV banking cards for ROCA vulnerability

TL;DR: A few weeks ago I've written a small Android app which allows you to extract the public keys (key chain) from your banking card, display them and check them for the ROCA vulnerability.

You can download the APK on Github: https://github.com/johnzweng/android-emv-key-test/releases

Long story:
Already a few weeks ago I started again to work with EMV banking cards (like Maestro, Mastercard, VISA).

Background was that a few weeks before a new vulnerability ("ROCA") was discovered, which affected the generation of RSA private keys within special secure chips from Infineon (see https://crocs.fi.muni.cz/public/papers/rsa_ccs17). Private keys which were affected by this vulnerability could be broken with relatively small effort (compared to secure keys).

As I remembered that most Austrian banking cards also contain Infineon chips and EMV cards use RSA keys for signing their data, I started looking into this topic again.


Background:
The ROCA vulnerability only affects asymmetric (RSA) keys (generated under specific circumstances by some Infineon chips).

In EMV cards there are used symmectric and assymetric keys for different purposes. Each card holds a securely stored symmetric key (the same key stored on the card is also stored in the bank's backend system). This key is used to verify that a transaction sent to the bank from a payment terminal was really made by the card which the bank gave to a customer (and not a cloned card).
So even if banking cards where vulnerable to ROCA you couldn't get the secret symmetric key used for transaction signing (so this part is safe).

But in each card we also have assymetric RSA keys (a key chain), which is used (by terminals and ATMs) to verify that the card data was signed by a valid bank certification authority (which itself has to be signed by a valid root certfification authority like Mastercard or VISA).

So we have a chain of trust starting at: card key -> bank key -> root card-scheme key (Mastercard,VISA).

This signature is used by a terminal or ATM to verfiy that all parameters on the card were actually set and signed by a trusted and eligible issuer.
This is especially important because of one property of EMV transactions: In simple words: in a transaction the card dictates to the payment terminal how the transaction should be performed.

For example the card can say: Hey terminal, it's ok to allow transactions up to the amount of XXX euros to be performed offline. So you don't need to go online and ask my bank, you can accept this payment immediately (offline).

The terminal trusts the card (although the terminal itself might decide for other reasons to still go online and ask the issuer bank) and will perform as the card said it should. This trust is based on the RSA signature chain, by which the terminal can easily check if the card was issued by a valid bank, which itself was certfied by valid root certification authority (Mastercard,VISA).


Possible impact:
So here we see the possible impact: If you can forge a valid signature from a bank you can create your own card, which looks valid to a terminal and could use it to perform offline transactions (as you could set the parameters on the card as you want).

This impact would be limited by security limits on the terminal side, which itself has its own settings (which amount it allows at maximum in an offline transaction).


Back to ROCA and real life consequences:
So if the bank keys or root ca keys were affected by the ROCA vulnerability this type of attack would be possible. As we remember ROCA only affected keys which were created within specific Infineon chips.
This means that the keys used in the certificate chain would needed to be generated within a vulnerable Infineon chip.

As far as I know this is not the case in the workflow of key generation and key handling with EMV, but I really don't know for sure (I'm not working in this field). I don't know how these keys are generated, distributed and managed.

I created small Android app, which recovers the public keys (in EMV they are not stored fully in the card but have to be recovered using the certificate chain).
After recovering the keys (Root-CA, bank, card) I use the tools provided by the team which discovered ROCA to check if the keys are vulnerable.


Just look yourself in the output of the app for the string ROCA vulnerable:. If this is true please contact me, as I would be interested which issuer created the card.

You can also check how strong (how many bits long) the used keys are. I was surprised to see that the key lengths are relatively short (but still safe).


Here a screenshot and link to my public Github repository where you can find the full sourcecode for this app as well as a readily built APK file for Android.

Github repo: https://github.com/johnzweng/android-emv-key-test


#ROCA #EMV #bankingcards #mastercard #visa #nfc #android

Photo
Photo
19.11.17
2 Photos - View album
Add a comment...

Post has attachment
Parity Multi-Sig Wallet Exploit:

As yesterday an "exploit" in the Multi-Sig wallet of the parity ethereum client became public, I looked into this and I cannot believe it:

The function in the Multi-Sig smart-contract which sets the owners and the spending limits ("initWallet") was public not protected with any modifier and therefore callable by ANYONE at ANY TIME:

So the "exploit" just went like this:

1) set yourself as new owner (call function "initWallet")
2) withdraw the funds (call function "execute")

I cannot even call this a hack. You just call 2 functions and the ETH is yours. OMG.

Also the fix is very simple (make sure that the "initWallet" only can be called during initialization): https://github.com/paritytech/parity/commit/b640df8fbb964da7538eef268dffc125b081a82f


After a blackhat hacker (this address here https://etherscan.io/address/0xb3764761e297d6f121e79c32a65829cd1ddb4d32) used this "functionality" to take around 150000 ETH (~$ 30 Mil) another group of white hat hackers started to search the blockchain for other instances of this vulnerable smartcontract and "took" another 377000 ETH (~$ 77 Mil) which they will return to their owners.


This is the address where the whitehats collected the funds:
https://etherscan.io/address/0x1dba1131000664b884a1ba238464159892252d3a

This like wild wild west.. I'm curious how will we see all these events when we look back in like 10 years or so. :)
Add a comment...

Post has attachment
My Nitrokey Pro has arrived

I was looking forward to receive my Nitrokey Pro (https://shop.nitrokey.com/shop/product/nitrokey-pro-3). After using the Yubikey Nano for some time now I was curious about the Nitrokey Pro as its hardware and firmware are both open source:

Firmware: https://github.com/Nitrokey/nitrokey-pro-firmware
Hardware: https://github.com/Nitrokey/nitrokey-pro-hardware

On the inside the Nitrokey Pro seems to be a PC/SC compatible USB smartcard reader holding a Micro-SIM sized (15 mm × 12 mm) smartcard.

The smartcatd seems to contain an OpenPGP compatible applet, as well as some other applet to perform the TOTP (https://tools.ietf.org/html/rfc6238) and HOTP (https://tools.ietf.org/html/rfc4226) operations, but I haven't looked yet into this in detail.

Below you find some pictures after I have opened the case (I placed the YubiKey Neo only for size comparison also there).

#Nitrokey #NitrokeyPro
PhotoPhotoPhotoPhotoPhoto
14.03.17
20 Photos - View album
Add a comment...

Post has attachment
No Open Mobile API on Google Pixel phones:

As Google did not include the 3rd party library "Open Mobile API" - which is needed to access the Secure Elements in SIM cards - in its Nexus devices I was curious if this is also the case with the new Pixel devices.


I downloaded Pixel and Pixel XL System image from the link in this thread:
http://forum.xda-developers.com/pixel/development/pixel-image-t3477107

The system images of both devices do not contain the "Open Mobile API". Without this API apps cannot access the Secure Element within a UICC (SIM card).

This means payment apps (or other apps) which use the SIM card as storage for their secure keys (Secure Element) will not work out of the box with the pixel devices (for example here in Austria the "Bankcard Mobil" aka "Bankomatkarte mobil").

If it will ever be possible to make it work by manually installing (flashing) these API (as I described in earlier postings for the Nexus 6) depends on the hardware of the phones. Besides the software (Open Mobile API) the phones would also need a special single wire connection (see also: https://en.wikipedia.org/wiki/Single_Wire_Protocol) between the UICC (SIM card slot) and the NFC controller chip (one pin of the SIM card must be physically connected to a special pin of the NFC chip). If this SWP connection is not present, it will be impossible to use NFC applications backed by the UICC Secure Element on these phones.


Host Card Emulation:
This has nothing to do with HCE (host card emulation). HCE apps simulate a NFC smartcard totally in software (without a physical Secure Element in the phone or SIM card) and get their data from a secure backend (cloud services). Examples for this kind of apps are Wirecard's payment app "boon" (at least the version here in Austria) and AFAIK also Android Pay. These type of apps will work on all modern stock Android versions.


Some of the build properties extracted from the system images:

Pixel XL:
ro.build.id=NDE63H
ro.build.display.id=NDE63H
ro.build.version.incremental=3256426
ro.build.version.sdk=25
ro.build.version.release=7.1
ro.build.version.security_patch=2016-10-05
ro.build.date=Thu Sep 8 18:55:20 UTC 2016
ro.build.date.utc=1473360920
ro.build.type=user
ro.build.user=android-build
ro.build.host=wpdt2.hot.corp.google.com
ro.product.model=Pixel XL
ro.product.brand=google
ro.product.name=marlin
ro.product.device=marlin
ro.product.board=marlin
....


Pixel:
ro.build.id=NDE63H
ro.build.display.id=NDE63H
ro.build.version.incremental=3256426
ro.build.version.sdk=25
ro.build.version.release=7.1
ro.build.version.security_patch=2016-10-05
ro.build.date=Thu Sep 8 18:52:11 UTC 2016
ro.build.date.utc=1473360731
ro.build.type=user
ro.build.user=android-build
ro.build.host=vpeb8.mtv.corp.google.com
ro.product.model=Pixel
ro.product.brand=google
ro.product.name=sailfish
ro.product.device=sailfish
ro.product.board=sailfish
....

Pixel System image
Pixel System image
forum.xda-developers.com
Add a comment...

Post has attachment
TL;DR: Bank Austria Automaten restoren defekte Magnetstreifen

Ich habe seit längerer Zeit das Problem, dass meine Karte zwar an allen Kassen und Bankomaten in Österreich funktioniert, nur an den Foyer-Automaten meiner eigenen Bank nicht ("Karte ungültig oder defekt").

Das Problem dürfte am Magnetstreifen liegen, den ich vermutlich unabsichtlich auf meiner Karte beschädigt habe. Meine Vermutung bisher ist, dass die Bank kundenspezifische Daten auf Track-3 des Magstripes speichert, die bei den bank-eigenen Foyerautomaten gelesen werden.

Beim Bezahlen an Kassen oder anderen Bankomaten ist das egal, denn da kommt nur der EMV Chip zum Einsatz.

Für mich als Kunde natürlich blöd, denn ich habe die letzten Monate immer aktiv die Automaten meiner eigenen Bank gemieden, wenn ich Bargeld beheben wollte.

Gestern habe ich es wieder einmal probiert und festgestellt, dass zwar wieder eine Fehlermeldung kommt, aber danach der Magnetstreifen wieder restored wird. Bei einem neuerlichen Versuch kam dann kein Fehler mehr.

Stellt sich die Frage:
Welche Daten stehen da jetzt eigentlich drauf? Offensichtlich kann der Automat die Daten ohnehin aus dem Backend holen und zum Abheben bräuchte es ja sowieso nur den EMV Chip. Wozu wird da der Magnetstreifen überhaupt benötigt?
Photo
Add a comment...

Post has attachment
Flickercode Testpage

Ich hab meine Testseite zum Herumspielen mit den CardTAN Flickercodes nun hier online gestellt: http://cardtan.zweng.at/
Sollte auch auf Mobilgeräten halbwegs funktionieren.

Wenn man "Show all details" anklickt, wird im Detail angezeigt, wie sich der Flickercode zusammensetzt (am besten dazu das Interval "ms per step" etwas größer stellen, dann sieht man schön, wie der Flickercode Schritt für Schritt funktioniert).

#cardTAN #flickercode #onlinebanking
Photo
Add a comment...

Post has attachment
Fun with a CardTAN Reader.. :-)

Mein CardTAN Reader ist gekommen und ich hatte heute Zeit mich ein wenig mit dem "Flicker-Code" (dieser "flackernde" Code zum Übertragen der Transaktionsdaten von der OnlineBanking-Webseite auf den CardReader) auseinanderzusetzen.

Ich habe mir dazu eine kleine Testseite gebaut und versucht, mehr über das verwendete Protokoll herauszufinden. Jetzt weiß ich zumindest mal, wie die Daten von der Banking Webseite in den CardTAN Generator übertragen werden.

Nächster Schritt ist herauszufinden, wie die Kommunikation zwischen CardTAN Generator und Bankkarte im Detail funktioniert. Mehr Infos folgen hoffentlich demnächst (wenn ich Zeit finde)..

#OnlineBanking #CardTAN #flickercode
Photo
Video
18.12.15
2 Photos - View album
Add a comment...

Post has attachment
Serial console on ESCAM Ant QF605 camera:

TL;DR:
I bought a cheap ESCAM Ant QF605 Wifi webcam, almost bricked it and revived it using the serial console.


Long story:
I bought one of these cheap 720p wifi webcams some weeks ago (to be specific, it was the "ESCAM Ant QF605").

The camera comes with an app (https://play.google.com/store/apps/details?id=com.nvsip.temp) and an online service which I both didn't want to use. So I just used the app for setting set up the camera (especially the WiFi password) and after that prohibited all internet access for the camera at my router and simply directly used the RTSP URL for accessing the h264 video stream:

rtsp://<camera_ip>:554/tcp/av0_0
or on older firmware versions:
rtsp://<camera_ip>:554/ch0_0.h264

The quality is not overwhelming but ok for the price. The camera by default also starts a telnet daemon on port and I found the root login online using Google:

User: root
Password: jvbzd

This way I found out that the camera runs thttpd and some single binary "/progs/bin/sctrl" which seems to do all the video stuff and opens the 554 port (providing the RTSP stream).

Unfortunately the camera also seems to have some problems. It gets pretty hot and keeps rebooting randomly every few days or hours (maybe related to the heat?).

Nevertheless, last week I tried to explore the boot process of the system and played around with some of the init-scripts, as suddenly the camera didn't seem to boot anymore. It never came online again.


In the first moment I regretted that I wasn't more careful and thought that I had bricked the device. But after opening I soon discovered 4 promising looking contacts on the PCB which turned out to be a serial line (rx, tx, ground and 1 pin unconnected).

By using my FTDI serial to USB converter I was able to connect to the serial console and got access not only to the U-Boot boot prompt, but also to the Linux console (fortunately the kernel was compiled with serial console).

Having this access I saw that the device did in fact boot, but was rebooting before the WiFi came up. To exit this boot loop I simply modified the boot parameters for the Linux kernel on the U-Boot command line, by adding the argument "single" which directs the kernel to boot into single user mode (just starting a shell and none of the startup scripts).


Maybe this information will help others so I attached pictures where to find the serial connectors on the board. I also attached a short video showing the boot loop and how I managed to boot into single user mode over the serial console.

Serial settings I used in minicom: baudrate 115200, 8N1, software flow control

I also attached lots of other images of the device for documentation.
PhotoPhotoVideo
Video
Photo
03.04.16
18 Photos - View album
Add a comment...

Post has attachment
Soeben getestet: Auch am Nexus 6P dürften SIM-basierte NFC-Payment-Lösungen nicht möglich sein

Danke an +Wolfgang Trexler der mir nach dem Nexus 5X nun auch ein 6P für Tests zur Verfügung gestellt hat.

Ich habe nun mit dem 6P ebenso zahlreiche Tests und NFC-Konfigurationsänderungen wie schon beim 5X durchgeführt, aber auch bei diesem Gerät scheint keine physische SWP-Verbindung zwischen dem NFC-Chip und dem SIM-Slot vorhanden zu sein (zumindest deutet aus Software-Sicht alles darauf hin).

Somit wird es niemals möglich sein (egal welche Software-Updates noch kommen mögen) SIM-karten-basierte Lösungen wie die Bankomatkarte Mobil (https://www.bankomatkarte-mobil.at/) mit dem Nexus 6P zu verwenden, da eine Hardware-Voraussetzung fehlt (nämlich die angesprochene SWP Verbindung zwischen NFC Chip und SIM-Karte).


Für Details siehe auch meine früheren Postings hier auf Google+ oder mein Posting auf stackoverflow: http://stackoverflow.com/questions/34251005/nfc-offhost-routing-to-the-uicc-on-the-nexus-5x-and-the-nexus-6p
Add a comment...

Post has attachment
Overriding OMAPI Secure Element access control with an Xposed module
http://forum.xda-developers.com/xposed/modules/mod-override-sim-secure-element-access-t3287184

For those who are interested, I've written a (little bit longer) posting on XDA about an Xposed module I've published a few weeks before on Github which shows that overriding the access control mechanism of the SIMalliance Open Mobile API can be done very easily.

Add a comment...
Wait while more posts are being loaded