Thursday, April 17, 2014

Kill switch your smartphone

Read:
Kill switches are originally intended for use as a remote method of wiping data off a smart device remotely. But history has shown that if you have a kill switch installed, if discovered by hostile parties can be used against you. If an attacker manages to find a way to send the correct command to activate the kill switch, it might disrupt or even endanger whomever owns this kill switch (imagine if you were to plant a remote kill switch into smart devices and these smart devices have some sort of link to life support systems for health patients, that would be really dangerous).

Remote wiping implementations are not so straightforward in it's designs and implementations. One have to consider the fields of economics, politics, social behaviours and most importantly, the technical side of computer security.

Relating to the technical side of computer security, some remote wipe providers may offer some form of strong symmetric key or PKI infrastructure to encrypt the communication between your smart phone and the remote command tool to send the kill signal, but what is going to protect these encryption keys or passwords from falling into the wrong hands ?

Once you have given someone the access to remotely send commands to your own system, you have effectively lost control over your system. That is the basis of computer security: which is to secure your system and prevent yourself from losing control.

For the economical, social and political side of matters, who truely owns the smart device ? Is the person who bought and signed the contract for the smart device the true owner of the device ? Are there political motivations for inserting political and governmental backdoors via the remote kill switch ? Are the service providers and software providers trying to gather more user data some mechanism in the remote kill switch for their own benefits ? There are much more to consider than the outright "benefit" of simply remote wiping your smart devices if it lands in the wrong hands.

Who would know if some malicious employees or someone within the the company or organization whom you have given remote wipe command access to might not intentionally or accidentally wipe your smart device or use the security loophole(s) of the remote kill switch to remote control your smart device ?

An alternative to using a blackbox style remote kill switch which you have no access or control over the source codes and mechanisms is to look for open source alternatives which you can review the source codes to ensure that there are no backdoors in the remote kill switch and the mechanisms in place to transfer the command to remotely kill a device is sent our via secure and conscious means. The problem with such an open source implementation is not everyone knows about computer security and how to evaluate codes to ensure that the codes and kill switch mechanics are safe. People are likely to simply purchase or subscribe to a kill switch without proper inspection and trust it which can be detrimental to one's own privacy and security.

In essence, deliberately introducing a loophole (remote kill switches are considered a deliberate loophole in CS field) into a system degrades it's overall security regardless of the intention or purpose.

Here are a few tips to secure your smart devices:
  • Never leave them on the table or chair or leave them unattended even for a few minutes if these devices contain personal data (phone contacts, email, address book, PIN managers, bank transaction applications ... etc).
  • Filesystem / Volume encryption.
  • Always use a Password Manager with a Master Password and never write them down on paper or Notepad.
  • Never share passwords.
Afterall, the best device security is yourself being cautious and aware of the surrounding. Depending on some loophole technology to remote kill your device is the worse idea.

Friday, April 11, 2014

What would have prevented Heartbleed

We all know the potential damage Heartbleed could have caused. So, what are the solutions that could have mitigated or prevented it in the first place.

I would attempt to rank what I feel is important for a security setup to protect it's keys.

  1. PROPER AND SECURE CODING PRACTICE WITH PROPER CODE REVIEWS!
  2. Use programming languages that will help lessen confusion and mistakes like these.
  3. Ensure that cryptographic libraries should be doing what they are suppose to do ! Cryptography is a hard subject and not everyone is good at this subject but everyone wants to use Cryptography to protect their digital assets. An application programmer who uses a particular cryptographic library may not properly understand encryption so it's hard to proof if the library is stable and "sane".
  4. Basic education on Cryptography to CS/IT/BIS students should be made mandatory due to the wide spread use of Cryptography in modern computing.
  5. Key handling to be performed somewhere else. Segregate the system into layers and sandbox. If one part is compromised, you have other layers to support and maintain a certain level of security.
  6. Integrate a FIPS-140-2 Level 3 or higher installation of  Hardware Security Module (HSM) to solely handle the keys. Keys should always be handled in a HSM with FIPS-140-2 Level 3 or higher environment whereby the keys will never leave the secure environment and the HSM should be in working condition clean of no recent tamper events. Not everyone can afford a FIPS-140-2 Level 3 or higher HSM so it's pretty much a luxury item for those who can afford them. For those who can afford these HSMs, they should be using them properly.

If you noticed, proper education and secure coding has been ranked on top of everything else. The reason is due to the fact that, no matter how good the libraries and hardware/software are, proper understanding and usage is the key to security. Most of the standard algorithms out there that are well known are usually secure. It is the mismanagement on the human aspect that is causing so much security problems.

Tuesday, April 8, 2014

Should I still use OpenSSL

OpenSSL does not have a good record of secure coding although they patch their codes very quickly. The most recent Heartbleed bug allows users to access the memory space (which also includes the keys loaded in the memory) from a direct connection to any application running the affected versions of OpenSSL.



What should you turn to next if you decide to drop OpenSSL from the list of SSL cryptographic providers? You might want to try out Mozilla's NSS and use the NSS to replace the leaky OpenSSL library.

Wednesday, April 2, 2014

Theoretical Insecurity of Bittorrent Sync

Bittorrent Sync (BTSync) is a new product created by Bittorrent company (whom also brought us the Bittorrent technology) for syncing your data between multiple endpoints or parties while leveraging the Bittorrent network and technology.

The product is a closed source product so all I can analyse is via the published details on their website.

I have not found time to sit down and try out the software and would not entrust my personal files to a closed source product to distribute them across the Internet for syncing therefore I may not have the most accurate picture of it's underlying protocol.

The BTSync technology claims to be "very secure" and here are the theoretical weaknesses that increases my discomfort and unwillingness to try it.

According to the Technology page of the BTSync product (bittorrent.com/sync/technology)...

  1. Uses Crypto API for Windows. - Please use a better cryptographic library that people have trust in like the Mozilla NSS and OpenSSL suite.
  2. According to the technology described for Peer Discovery, BTSync sends out SHA1(Secret):IP:Port to solicit response. It is as good as tell the world that your IP address and Port is open for a specific protocol without people needing to probe your network at all. Sending out a SHA-1 hashed Secret is the greatest danger in this PEX protocol. It is as good as handing out an obfuscated secret key to the world and if someone copies it, they could match it against a rainbow hash table and compromise your security. The better way to do a secret key negotiation and authentication protocol is to secure randomly generate a one-time secure random and use your secret to encrypt the one-time random and distribute it via a key exchange protocol.
  3. Sync Trackers and Torrent Servers are a good way of caching your communications and key exchanges. It is as good as giving your adversaries a public cache of your activities. If you want serious security, you should leave as little traces as possible. Metadata are obviously one of the best traces as you can create an activity record more easily.
 Now we have seen the theoretical major weaknesses of Bittorrent Sync, let's try to fix it.
  1. For the cryptographic APIs, use NSS and OpenSSL. These are highly recognized and open source libraries. For randoms on Unix systems, use the urandom.
  2. The PEX protocol requires an overhaul to include a much more Shared Secret Exchange Protocol I shall describe here (SHASEX). For this SHASEX protocol, it shall remain in the public, unlicensed and unpatented forever and I genuinely am unaware of any such patents or inventions/creations when I write this SHASEX protocol version 1 here.
    1.     We shall assume that all clients have the same shared secret key loaded (K).

    2.     The party that requests communication to all clients generates a random (R) and uses the secret key shared amongst them (K) to encrypt R. Thus, EK(R) and sends it to everyone known.

    3.     Since everyone has the same shared secret, everyone decrypts the random which is no used as a shared negotiation key so that every client can establish their unique session keys. All clients would randomly generate their own session key independently with the requestor. Let U be the unqiue random each client generates at random for their own session keys. Now all clients would use the R random to encrypt their U random thus. ER(U) and sends it to the requestor.

    4.     The requestor would consolidate all the client's session key, U, and communicate to them using their own session keys (no sharing of session keys for privacy).

    5.      By this method, when an attacker from the outside looks at this protocol, all he sees are encrypted values moving around, not plain hashed keys. When the attacker views the session keys, they will have values that are not the same due to the usage of different session keys. Thus, if an attacker were to collect all the encrypted session keys, he would need to break a variety of keys in order to get to the same data and the same data, due to being encrypted with different session keys that are securely generated, would also appear different thus making cryptanalysis even harder.

    6.     The weakness of this SHASEX protocol to my knowledge and is an unintended consequence of such distributed, decentralized and lightweight design would be to compromise one of the clients hosting the same shared secret keys, intercept all their keys and do a man-in-the-middle.... that if ... the attacker manages to know the secret key by compromising any of the clients. To prevent the stagnation of secret keys, it is best to discard and regenerate shared secrets everytime a session has been ended. The requestor would have to generate a random shared secret and encrypt them with the session keys, distribute the secrets, before closing the connection.

  3. To try to lessen footprints on servers and trackers, try to use less of them.
These are all the comments and recommendations I have now for the improvement of the BTSync protocol.