User:Milosch

= Milosch Meriac =

Short Introduction


I have over 20 years of professional experience in embedded programming, hardware development and the information security business. I love breaking things. My most recent work was breaking iCLASS RFID Standard security - see HID iCLASS™ security demystified and Heart of Darkness - exploring the uncharted backwaters of HID iCLASS™ security.

In my private time I love making/grokking things. I am currently playing with RGB strips to create light paintings and counter-advertising bags.

I am Co-Founder of active and passive RFID open source projects like Sputnik/OpenBeacon, OpenPCD and OpenPICC and I am committed to RFID related security research. As a member of the Blinkenlights Stereoscope Core Team I designed the 2.4GHz OpenBeacon based wireless dimmmer and Ethernet WMCU Hardware that was used in the Toronto City Hall Installation. As one of the three maintainers of the former Xbox-Linux Project I helped breaking the Xbox security and ported the first Linux System to the Xbox.

My focus is on hardware design, embedded systems, RF designs, active and passive RFID hardware development, custom-tailoring of embedded Linux hardware platforms, real time systems, IT-security, hardware & software reverse engineering and security evaluations of embedded systems.

Need Help ?




If you have interesting projects available or need my help - feel free to [mailto:milosch@meriac.com contact me] at meriac.com for:


 * Active/Passive RFID
 * Hardware development (Consumer electronics and Industrial test equipment)
 * Reverse Engineering and IT-Security
 * Embedded Systems design
 * Realtime drivers
 * Low-level Programming
 * Linux Driver and OS development

My GPG/PGP Key ID is C8C1 EB07 C743 58FB 1259 5ED9 708B 8D3E 15D5 2B9F

= Things I do =
 * Light Painting using my LPD8806 based RGB strip (117 RGB LEDs). Find the source code for RaspBerry Pi B+ and for the Olimex LPC1343 development board
 * Demystifying HID iCLASS™ security: Look into the Heart of Darkness and explore the uncharted backwaters of [[Media:HID-iCLASS-security.pdf|HID iCLASS security]].
 * Things I randomly tweet about
 * Some random Linux shell snippets which I regularly use.
 * OpenBeacon GPL'ed 2.4GHz RFID Tracking System
 * OpenPCD - GPL'ed passive 13.56 MHz RFID reader for security research with Mifare Classic support
 * OpenPICC - GPL'ed RFID tag emulator
 * Camp Tipsy Pictures

= Things I find interesting =


 * All Watched Over by Machines of Loving Grace - An excellent documentary about the origins of our economic system, its philosophy and the origins and early mistakes of internet based democracy.
 * Laser Isotope separation and the future of Nuclear Proliferation
 * Girl sneaks into russian rocket factory and takes amazing pictures
 * Video of Beethovens 7th, Allegretto, 2nd Movement visualized graphically
 * The Secret Document That Transformed China
 * The Buddha of Fukushima’s Forbidden Zone: A Photo Essay
 * Why Programmers Work at Night
 * Amazing macro photos of insects
 * High resolution weather satelite images
 * Gallery of U.S. nuclear tests
 * Rapatronic nuclear test photographs
 * The Nuclear Weapon Archive

= Breaking good Cryptography = Cryptography did become an important part of our life. Thanks to Kerckhoffs's Principle proprietary and an undocumented algorithms are finally on the verge of extinction as new products use documented and well-researched algorithms. I regularly stumble over good cryptography that is broken by a bad implementation or wrong usage.

Hints & real world fails

 * Kerckhoffs's Principle: Never store secret keys in your application binaries. This statement applies recursively: It doesn't help to encrypt a secret key with another key hidden in the application binaries. Assume for your security assessment that sophisticated attackers can read your application binaries as easy as you read your own source code. Simply assume that your attacker is in possession of your full source code and the comprehensive protocol/data format documentation. Security by Obscurity never worked and every obfuscation can be reversed.
 * Reverse-Engineering a Cryptographic RFID Tag: Shows how a pseudo random number generator kills security by allowing to control the 'not-so-random-anymore' challenge and thus allows to replay a sniffed response to the challenge.
 * Implementing an RFID 'Mifare Classic' Attack
 * Broken Random Number Generation: Don't laugh too hard - as many people make that mistake by involuntarily making their random numbers predictable by using a library-Randomize functions for their integrated pseudo-random number generator - making their random numbers predictable by guessing the time the program was started.
 * Console Hacking 2010 - PS3 Epic Fail: Broken Elliptic Curve Digital Signature Algorithm (ECDSA) by using the same 'random' number over and over again.
 * Using the wrong cipher mode: Theory and Practice of Cryptography: Excellent paper with a lot of do's and dont's like ECB used where CBC is needed (p13-15),
 * 17 Mistakes Microsoft Made in the Xbox Security System Using TEA encryption as a Hash is evil (see page 8). Exposing the encryption key on a external bus is not a good idea as well.
 * Don't encourage attackers by using the same keys for multiple devices or RFID/smart cards: For example HID iCLASS standard security cards use the same key all over the world: Heart of Darkness - exploring the uncharted backwaters of HID iCLASS security making it a promising target for complex attacks. This could be easily avoided if per-customer keys were used more consequently.
 * Be aware of a major RSA pitfall - RSA has the property that the product of two cipher-texts is equal to the encryption of the product of the respective plain-texts. This means if you can slip in a known plain-text and have it encrypted with the same RSA, you can calculate the original plain-text from that. This is easily avoidable if you use padding.
 * Using a cipher doesn't automatically result in transaction security: Many stream ciphers allow modification of a known plain text for unknown keys as usually a pseudo-random stream of bits (a key-stream) is generated which is XOR'ed to the plain-text.
 * Don't use the same RSA key set for signing and encryption.
 * Carefully examine possible physical side channel of your actual encryption device. A good example are Differential Power Analysis (DPA) attacks, timing attacks like the remote timing attacks on Elliptic Curve Digital Signature Algorithm (ECDSA) are are still practical.
 * An important class of attacks you need to be aware of are fault injections. Fault injections are not only limited to software, but are also true for the hardware - for example clock/power glitching to skip parts of your code to circumvent security checks.
 * Understand man-in-the-middle attacks: Even SSL encryption doesn't help if you don't get your PKI management right: For example in the german eID management software the certificate-hostname wasn't compared to the the actual host name. This allowed a man-in-the-middle attacker to pretend to the management software (AusweisApp) that an update was available - resulting in a download and remote code execution via directory traversal.
 * Use a good random source with adequate entropy - reseed constantly by using unpredictable events. A key is only good as the random source used to create it.
 * Are you using PGP/GPG for email encryption? Did you consequently verify the key fingerprint both ways with your communication partner (either by phone if you know his/her voice or by personal verification). Reading it off a website doesn't help - even if it's SSL encrypted. As the Web of Trust usually has holes, people tend to blindly sign new key blindly or after comparing fingerprints from a website or by sending around their keys via plain-text mail. A simple solution is to print your full key fingerprint on your business card or publish the fingerprint in a newspaper.
 * A variation of the fingerprint verification problem is SSH: how often did you open an SSH connection on a new machine to one of your servers without verifying the fingerprint?

Summary
Don't try to protect a tent with a safe vault door: Make sure that the other components in your system live up to the security level of the cryptography you use. A good example are buffer overflows in your code resulting in remote code execution and unauthorized access - or Differential Power Analysis (DPA) - or mechanically breaking the wooden door open that is protected by a 2048 bit RSA key protected biometric smart card... or ...