Category Archives: computer security

Advances on Quantum Cryptography


I gave this talk about Quantum Computing and Quantum Cryptography some years ago. But after reading a lot of papers about quantum decoherence, I decided to left the field as the prospects were not very enticing.

Notwithstanding, this month has emerged with very interesting research (and it’s not the first sale of quantum computation device):

Books on Mobile Security

All the recent news about the Android and iPhone smartphones storing geo-location data without the user’s knowledge and consent are just the tip the iceberg of the very long history of the clash between the growing functionality of mobile phones and the unawareness of the userbase, and a omen of what’s to come in the ever increasing privacy erosion created by the digital world. The applications to uncover the hidden features are freely available (iPhoneTracker, Location Cache) and it was their very own existence what propelled the public worry and interest.

Yet as Scott McNealy, CEO and co-founder of SUN, once said, “You have zero privacy anyway, get over it”: a truth best-known to computer scientist but hardly understood by the general public.

I’ve also been reading the very small list of books written on mobile security, and these are my recommendations:

  • [amazon_link id=“1439820163” target=“_blank” ]Mobile Device Security: A Comprehensive Guide to Securing Your Information in a Moving World[/amazon_link]. Very high level and non-technical overview of the new mobile paradigm for computing and communications, covering the threats, risks, scenarios, business cases, security models and policies of organizations. Technical readers will be highly disappointed.
  • [amazon_link id=“0071633561” target=“_blank” ]Mobile Application Security[/amazon_link]. Recent book covering all the topics required to master mobile application security, making it a very good compilation of all the data currently scattered all over the net. It covers all the mobile operating systems, even the disappearing ones (Windows Mobile, WebOS, Symbian, Java ME) and the specific mobile technologies (Bluetooth, SMS, geolocation). An expanded chapter on enterprise security on the mobile OS would be preferred.
  • [amazon_link id=“1597492981” target=“_blank” ]Mobile Malware Attacks and Defense[/amazon_link]. A wonderful technical and historical reference on mobile malware and other mobile threats, with an emphasis on forensic techniques applied to the different mobile platforms. It shines at its comprehensiveness, as it lists almost every technique, malware and software known as of its publishing date. The only shortcoming is that Android is not mentioned since the book is a bit dated.

Android Decompilation & Obfuscation

I get more than a hundred visits a day to my iPhone Decompilation & Obfuscation post, that’s why writing an Android equivalent and comparing the results between them will be so interesting to assess platform demand from developers.

To decompile an Android .apk file, you must follow the next steps:

  1. Download the app from the Android Market to your smartphone and backup the app with a tool like Titanium to get the .apk file
  2. Next, use apktool to get back the project file structure and resources
  3. Then, use dex2jar to the obtain .class files from the .dex files
  4. After that, use jd-gui or JAD to decompile the .class files
  5. Most bytecode won’t perfectly decompile and some routines will be hard to reconstruct from the bytecode: get ready to read java ASM disassembled with smali

To obfuscate/protect your application, consider following these steps:

  • ProGuard is the most complete and useful tool to obfuscate applications, but you must use it with the following configuration file to avoid any problem. Note that ProGuard is pre-packed in the SDK from Android 2.3
  • Use LVL for your paid applications, but remember that it has already been broken.
  • Lastly, consider using Android NDK for the most critical code. Writing JNI code is a really cumbersome and error-prone, process that’s why using specialized tools is essential to avoid errors and speedup development: to interface C libraries with Java, try SWIG and  GlueGen; in reverse, to interface Java with C try HawtJNI. It’s a pity that the Integrated Debugger for Java/JNI Environments is only available for the Apache Harmony JVM, as it really helps in the difficult Java/JNI debugging process.

As a final note, the results from the superb paper “On the (Im)Possibility of Obfuscating Programs” will always tame our aspirations in the obfuscation enterprise:

GDE Error: Error retrieving file — if necessary turn off error checking (403:Forbidden)

Advances on DoS Mitigation


I spoke at a conference about the Prevention, Detection and Mitigation of Denial of Service Attacks years ago. Reviewing its content, I’m surprised of how current the information is even now, at least for level 3–4 DoS attacks: it’s true that there are newer techniques, but for all intents and purposes they are still the same procedures.

If I were to repeat it, the one thing I would add for sure is the recently released Roboo, the HTTP Robot Mitigator, a level 7 tool that verifies the existence of full browser stacks using advanced non-interactive HTTP challenge/responses mechanism to detect and mitigate HTTP robot and DoS attacks.

Code battling code battling… (ad infinitum)

pMARS, the official Redcode simulator

Battle programs of the future will perhaps be longer than today’s winners but orders of magnitude more robust. They will gather intelligence, lay false trails and strike at their opponents suddenly and with determination.”
‑A. K. DEWDNEY, Computer Recreations, Scientific American (January 1987)

Mahjong is different from Checkers, just like High Frequency Trading is different from Core War: they include the profit motive!

Code of Virii Set in Silicon

I’m eager to learn the outcome from Intel’s biggest acquisition ever, McAfee. As company representatives have said in a conference call with Wall Street analysts, they plan to push functionality down from userland to the die chip, just below the OS. And that is a really bizarre rationalization for this acquisition, since antivirus are memory and I/O bound processes, not CPU-bound applications (see “Characterizing Antivirus Workload Execution” for more information), that’s why significant speed-ups aren’t likely to be attained. And all improvements Intel is going to put into the chips should be also offered to other antivirus companies, otherwise they risk facing antitrust action as the EU has forewarned, coincidentally the same reason Microsoft hasn’t be able to make a good antivirus even if everybody would benefit from a development like that (ironically, the last one being a case of a public bad from public intervention).

Security on a chip should be as simple as possible. I still remember the security fiasco within the Intel 286 ring model caused by an undocumented instruction, LOADALL, which rendered it useless. In my opinion, progress will be more in the vein of current virtualization offerings, seeking to improve performance with multiple virtual machines within a host.

Finally, note that EBITDA margins aren’t exactly attractive, in particular for a company like Intel:

[trefis_forecast ticker=“INTC” driver=“1318”]

The ROI Fallacy in CompSec

The script is always the same: first, an estimation of the expected loss from an intrusion or attack is provided; then, a proposal of countermeasures that are some orders of magnitude cheaper that the expected loss is suggested; in conclusion, the solution being offered features such a high ROI that only a fool will discard it, so runs the argument. Repeat for every antivirus, IDS, firewall or whatever security product being sold.

This myth is based on a loaded use of language that equals the notion of expending on security with that of an investment, a misleading and self-serving broken framework of economics that isn’t taking into consideration other variables like opportunity and hidden costs. As in the parable of the broken window, disregarding the ideal world in which nothing gets broken and the resources could be better put into use for other much more productive purposes leads to very misguided conclusions. That is, security is not an investment, and insecure programs don’t carry debts.

Computer security is a tax.

Different operating systems carry different levels of taxes: desktop Window carry a higher level of computer security taxes due to malware. And programming languages also differ: the tax bracket for ColdFusion is higher than the one for C, which is higher than the one for Java/C#.

And since software vendors aren’t liable for their insecure products, they have no incentive to internalize the hidden costs of security breaches and transfer them to customers, who must spend resources to protect their real assets, like the taxes citizens pay to governments to provide for security services.

Baumol’s Cost Disease in Computer Security

The most creative parts of computer security are undecidable or NP-hard problems, a fact that creates a big divide in the computer security field: on the one hand, bug finding, exploit writing, secure code auditing and cryptographic protocol design are the most difficult tasks in the field to apprehend and resolve; but on the other hand, the pentesting process is largely better left to be done by software than by humans. The key insight is that no capital-labor substitution will ever take place in the first kind of activities, therefore productivity gains will never be achieved on them no matter what amount of innovation will ever be carried out in the next decades: that is, the same man-hours will be needed to produce the same amount of work in the future, if not more so, taking into account the exponentially rising number of computer systems and software components and their interactions.

And that is the depiction of the archetypal setting in which Baumol’s Cost Disease arises: tasks with no labor productivity improvements for decades, but with raising labor costs nonetheless, to keep up with the rising salaries in other jobs which did experience such labor productivity growth. The side effect of the disease, which makes it so nefarious to the computer security field, is that the best talent is lost to other tasks in this  process of constant readjustment.

Presentations about Smartphone Security

A list of the best presentations about smartphone security all over the net:

Note: this post will be expanded in the future.

Traitor Tracing: Theory vs Practice

An efficient public key traitor tracing scheme

We construct a public key encryption scheme in which there is one public encryption key, and many private decryption keys. If a broadcaster encrypts once with the public key, then each legitimate receiver can decrypt with a different private key. If a coalition of receivers collude to create a new decryption key then there is an efficient algorithm to trace the new key to its creators. Hence, our system provides a simple and efficient solution to the “traitor tracing problem”. Our tracing algorithm is deterministic, and catches all active traitors while never accusing innocent users, although it is only partially “black box”. A minor modification to the scheme enables it to resist an adaptive chosen ciphertext attack. Our techniques apply error correcting codes to the discrete log representation problem.

The most cited traitor tracing crypto-scheme versus… the Black Sunday hack:

Among the countermeasures he says he created was one known among pirates as the “Black Sunday” kill — an elaborate scheme that destroyed tens of thousands of pirate DirecTV cards a week before Super Bowl Sunday in 2001.

Instead of being delivered all at once like other measures, the Black Sunday attack code was sent to pirate cards in about five dozen parts over the course of two months, like a tank transported piece by piece to a battlefield to be assembled in the field. “They never expected us to do this,” Tarnovsky says.

Why stop at tracing traitors when you can wipe them out? Very clever.