Techno-Politics and Journalist Security in Singapore

Read:

• https://sg.news.yahoo.com/singapore-pm-demands-apology-blogger-084428281.html

Three generations of Singapore's top officials have used the tactic of forcefully pushing bloggers and vocal Singapore netizens against the wall via legal threat. Instead of using peaceful debates to proof to the netizens that their accusations are baseless, these top officials of Singapore have chosen to use unrestricted force upon sight to bring down anyone who are against them.

In my opinion, the accused officials should step up and take challenges instead of using unusually forceful means to subdue the views of those they find unpleasing and learn some humility and appreciation for the comments of others regardless if they are nice or not. To prove that the accuser is wrong, they can make their processes very transparent and invite outside parties to audit their systems and processes. If they can take challenges and show humility, not simply trying to get rid of others who they don't like, they will gain respect and respect is key to their reputation. The inverse which is simply being full of themselves and attacking by unusually forceful means would not gain much reputation. They simply look very ugly.

Put it simply, in Singapore, you need to publish articles that will not disagree with the people in power. Disagreement in itself is seen as equivalent to treason here. There is very little security provided to journalists and bloggers who want to post materials that may not be suited to the views of those in power as they may not take lightly any attempts at challenging their power and reputation. Below are some security mechanisms journalists and bloggers can consider below on taking a DEFENSIVE stance to protect themselves and their assets:

• Data hosted in foreign jurisdictions. This means that if someone wants to challenge you to take your data down, you and the aggressor need to obey the legal proceedings of the jurisdiction where the data is hosted. The very nature of jurisdiction if used properly can make it harder for an aggressor to push their way through. You need to pick your data hosting countries properly. Switzerland and Germany is a good place to start. Certain Scandinavian countries would also provide good data protection laws.
• Rally more debate if threatened. Get more attention and more support whenever can while maintaining OPSEC (Operational Security) as posted in this article.
• Data duplication and high-availability options. Create mirror backups of contents that are sensitive. Copy and distribute copies of works as often as you can. Use 7zip, Gzip and other compression formats to compress large data archives and upload them on online upload storage (DO NOT use Dropbox as they are pro-Institutions) and spread the links. Run torrents if you need to. Using this method, if one person (most likely you) go down and brought down, there will be many other like-minded ones who will continue to bring the debate back online.
• Proper use of Cryptography to protect their personal data and the protection of secret keys and passwords/passphrases despite coercion. 7zip archive format includes AES encryption to encrypt your own files with passwords. Have a good sense of password policy (mix characters with 12 characters and do not re-use passwords at the very least). Use of the Truecrypt file encryption utility would save you and make it absolutely difficult for agressors to decrypt your file as long as your master passwords and encryption keys are safe. Do not reveal passwords/passphrases under coercion.
• Use of PGP/GPG email encryption will enable private communications. Make sure to install Truecrypt and create a secure file volume and generate your PGP/GPG ermail encryption keys inside the Treucrypt secure volume so that your secret email keys would not hang loosely in your untrusted PC !
• DO NOT USE THESE ALGORITHMS FOR ENCRYPTION: RC4, DES, 3DES/TripleDes.
• DO NOT SHARE ACCOUNTS, PASSWORDS AND SECRET KEYS !!!
• Do not post something online when you don't want it to be known. Whatever data posted online and collected by aggressors would be used against you to remove your credibility, so for goodness sake, keep your online activities clean from now on and have a good security habit. Try to use HTTPS whenever you can (you can install HTTPS Everywhere browser plugin (https://www.eff.org/https-everywhere) and it will always steer you to a HTTPS connection whenever possible).
• If you are in an untrusted environment, use a TAILS Linux Live CD (https://tails.boum.org/index.en.html).
• Keep a separation between sensitive personal information and public information for goodness sake. If you need an air-gap computer (a computer that has no network by switching off it's network capability or physically removing it's network card and using USB stick to transfer sensitive information) to process sensitive personal information.
• If you are more technically savy, try to setup your own Rubberhose Filesystem (https://web.archive.org/web/20110726185300/http://iq.org/~proff/rubberhose.org/).
• Lastly for this article, all these troublesome security is in place to KEEP YOU SAFE.

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.

Lessons for Crypto-Currencies

There is an increasing frequency in the number of break-ins and stealing of crypto-currency wallets from individuals, online crypto-currency exchanges and cryot-currency "banks". Some "dooms-day" advocates whose agenda is to erase crypto-currency from the face of the world or to exploit such situations would hype up these break-ins.

It is not the end for crypto-currencies as the concepts and ideologies that led to the birth and blooming of crypto-currencies are rooted in the dismay and hopes of people who want to see some sort of currency that would allow them to gain more control and trust in the currencies they use.

In this post, I would give some suggestions on how to increase the security of existing and future crypto-currencies.

1. Secure that wallet !!
The weakest security in most protocols are the end-points as most protocols simply add end-point security as some sort of an after thought. Protocols should be designed secure for both data in transit and data at rest.The usual rant for end-point security...
• Use strong and well recognized cryptographic algorithms to encrypt wallet data.
• Use a well audited and well-known cryptographic provider API/software when coding those end-point security codes.
• Do not use passwords as raw input for cryptographic engines or store passwords in raw form.
• Design a time-out that would occur when users present too many wrong passwords during login.
• Try to clear away unused sensitive materials (wallet credentials and keys) from the computer memory as soon as possible.




2. Disposable secondary keys.
Carrying a secondary "credit card" which can be disposed readily is a nice to have feature for crypto-cuurrency. Carrying one's crypto-currency all over the place would mean your wallet is prone to someone grabbing it or you losing it by accident due to carelessness. Allowing a "bank" or some form of centralized authority to govern your crypto-wallet is a bad idea as it makes you "un-anonymous" as your identity would become tied to some known crypto-wallet. Crypto-currencies were designed to be decentralized, so please keep it that way and not allow some form of central management to escrow your crypto-currency assets.

Borrowing the idea of having your main crypto-currency private key (root key) as your root "Certificate Authority", you can independently generate as many independent transaction keys (you do not need to use the main private key as a seed to generate sub-keys of any sorts) and then use your root key to cryptographically sign (sign) your transaction keys and you carry these transaction keys with you to do crypto-currency transactions whenever you want. Any transactions using your transaction keys is as good as using your root key until your root key signs a "revocation announcement" that would disable the transaction keys (in cases where your transaction keys get stolen or you just want to disable them) you specify from performing anymore transactions. The crypto-currency protocol implementing such a method would have to support some form of invalidation and revocation of keys and auditing of keys and transactions (protecting transactions that uses invalid or disabled keys from executing while still retaining anonymity and decentralized structures).

Overall, crypto-currencies are a valid innovation and would still draw huge attention and experience large fluctuations of their values. It is about time the creators and maintainers of existing and future crypto-currency sit down and reconsider what I said above.

Spying on Skype

Read:

• http://www.conceivablytech.com/8108/products/microsoft-may-add-eavesdropping-to-skype
• http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=1&f=G&l=50&co1=AND&d=PG01&s1=20110153809.PGNR.&OS=DN/20110153809RS=DN/20110153809

As always, do not trust others until you have confirmed it is secure. I have never simply trusted something and including Skype. Legal intercept is simply a good excuse. It's the same as key escrows and we have already known from history, it's easier to have a backdoor than to try and fight a protocol itself. Another new item to distrust completely, Skype. Because it's closed sourced, it's a walled garden and now the owner wants to add eavesdropping for "legal" uses. Who knows which employee would have some fun sitting behind their desktops and making jokes on intercepted Skype conversations and posting funny calls on the Youtube for all to have fun and merry ?

Crypto Hash Lifecycles

Enjoy:

• http://valerieaurora.org/hash.html

Interesting view on how people usually react to cryptographic hashes that are about to be broken or broken.

Psuedo Password Encryption

Watch:

• http://www.arthursucks.com/2011/01/md5sum-ascii-encryption/ 

You simply use 'echo -n "" | md5sum' which simply sucks. If someone uses your terminal, they can check the history and you are gone.

Another thing to note, hashing password is NOT ENCRYPTION. Encryption uses an unknown factor called a key (layman term: a password or passphrase) !

You can also make a rainbow table or in simple terms, md5 hash all the possible passwords into a table and then match the hash and see which one matches and that's the password.

What happen if you simply clean out the history of your terminal / command line ? Doesn't that mean you are done and you need to click on the 'Forget Password' link ?

Please don't use such disingenius way of 'protecting password'. Use a proper password manager that uses properly implemented cryptographic ciphers that are true and tested to withstand attacks like the AES finalists: Rijndael, Serpent and Twofish.

Hashing is always a bad way to store password. Encrypt the password with a master password is always the way to go using a properly implemented cryptographic Password Manager.

A password manager I made: PasswordStore.