One of the first examples of IoT and security risks

Posted on by

Among IT practitioners there are a lot of ideas and discussions on the “Internet of Things” (IoT) and the security risks associated to them.

If IoT has many positive and useful future developments, the security aspects are very difficult to manage to the point of posing a very big question mark on the idea itself of IoT.

One example is described in the research “House of Keys: Industry-Wide HTTPS Certificate and SSH Key Reuse Endangers Millions of Devices Worldwide” published by SEC Consult, which shows how many hosts, typically home and SOHO routers for internet access, use the same cryptographic keys, which are public and well know, so that anyone can impersonate them and anyone who can intercept their traffic can decrypt it.

Even if the impacts of this vulnerability are probably not very high, it seems extremely difficult to fix, since the new devices will be fixed but the millions already in use will probably never be fixed and will remain active for a few more years.

Even more worrisome is that these are IT devices developed, built and sold by IT companies that should known about IT and IT security. What will happen when billions of devices will be connected to internet (the real IoT) developed, built and sold by non IT companies?

Homomorphic encryption and trusting the Clouds

Posted on by

Homomorphic encryption is an old idea but only in 2009 and the work of Gentry started to have some possible practical applications. Since then there have been quite impressive improvements in the research in this field of cryptography, also due to the need to improve the security of data managed by Cloud systems.

In brief, homomorphic algorithms are cryptographic algorithms that allow to do computations, like sums, multiplications, searches etc., on encrypted data giving encrypted results, without knowing the encryption key.

It should be obvious that these algorithms would be very useful for Clouds’ applications since the owner of the data would be able to use the data remotely by keeping at the same time the data, and the result of the computations, always encrypted in the Cloud application.

Unfortunately homomorphic encryption is not ready yet for general use, but it has just appeared an interesting research paper by Microsoft Reasearch announcing the release of a SEAL (Simple Encryption Arithmetic Library), a library for using homomorphic encryption in bioinformatics, genomic and other research areas.

Cryptography is too risky: should we use something else to secure IT systems?

Posted on by

Obviously the title of this post is provocative, but reading some recent news it is evident that us, IT professionals and IT industry, are not good in managing cryptography. The consequence is that we deploy cryptography in IT products and give a false sense of security to the users. This actually can have worse consequences than if we would not use cryptography at all. I will give just a couple of examples.

This research paper shows how a well-known brand of hard disks has implemented disk encryption in totally faulty ways, to the point that for some disk models hardly any security is provided by the built-in disk encryption functionalities. This is just another of many similar cases, where cryptographic protocols and algorithms are incorrectly implemented so to cancel all or most of the security that they should provide.

Another research paper shows how a well-funded agency or corporation can in practice break the encryption of any data encrypted with the Diffie-Hellmann (DH) key exchange algorithm using keys up to 1024 bits included. Should we be shocked by this news? Not really since already 10 years ago it was known that a key of 1024 bits is too short for DH. Indeed, as per RFC 7525, a 1024 bit DH key offers a security less than a conventional bit security of 80 bits, but again RFC 7525 states that the absolute (legacy) minimum required conventional bit security must be 112 bits, and the current minimum required conventional bit security is 128 bits, that would practically correspond to a 2048 bits DH key. Even if we, IT professionals and IT industry, have known for at least 10 years that 1024 bits DH keys are too short to offer security to the data that they should protect, as of today a too large number of HTTPS websites, VPNs and SSH servers use DH keys of 1024 bits or less (see again the research paper mentioned above).

Unfortunately these are not two isolated examples, recent news are full of similar facts. So I start to wonder if we are good enough to manage cryptography or if we should look into something else to protect IT systems.

The OPM hack and Biometric Authentication

Posted on by

For a long time, biometric authentication has been considered to be the safest and more secure way of identifying users and granting access to IT and non-IT services. It has just one serious drawback: you cannot change the biometric credentials, this is centainly “you”, and if your biometric credentials are stolen, someone could impersonate “you”.

This is what has happened in the OPM hack, the latest news reports that 5.6 million fingerprints of USA federal employees have been stolen, see wired for example. Information about this is scarce and it is not clear which is the format of the stolen fingerprints and how easy it could be to reproduce them. Security experts believe that it will be possible, sooner or later, to reproduce them, it is just a question of time, technology and money.

So what about the persons who have their fingerprints stolen and possibly reproduced by others? What about the security consequences for companies and the state?

How can we use the security of biometrics without the associated risk of impersonation?

A new dress for my website … and thoughts on net “sociality”

Posted on by

Today I released a new version of the UCCI.IT website: a new, responsive, graphic format which has a nice display on all devices, from the standard desktop PC to the smartphones, and a complete revision and re-organization of the material.

This lead me to think again about what it means to be on-line, to divulge information about ourselves to the internet world, which by now is a big part of the real world.

I do not really know the answer to this question, I just see that we keep changing the way in which we use the internet as a tool to communicate. This is related to the introduction of new or improved technologies, but also to the current trends: a few years ago we were all for websites, then for blogs, after that for social networks (which are still really going strong) but recently I found myself going back to the very old, almost pre-internet, email-list technology. I hear friends say that they have almost closed down their website and/or their blog, others who have left the social networks, others who do not use email anymore but only a chat App on their smartphones. It seems to me that we are confused, or, at least, I am confused.

I close with the following personal notes that I wrote a couple of years ago:

Dilemma: air my ideas on the cyberspace, get friends and followers or keep it all to myself and the occasional (voice) chat?

Where does privacy end and community begin?

On Ashley-Madison passwords crack

Posted on by

The Ashley-Madison story just got more interesting with the news that it has been possible to crack the supposedly well encrypted users’ password. As Ars Technica (among others) reports, the account passwords have been managed with bcrypt, and this makes it practically impossible to decrypt.

But the account passwords have also been used to create tokens related to the user’s sessions. In this case the password has been hashed with the broken algorithm MD5. From the token it is then easy to recover a lowercase version of the password, and with just a few tries, in some cases even as few as 256 iterations, it is possible to recover the exact password from the bcrypt encrypted value.

This is again another confirmation that security is not a feature to add somewhere in our IT systems, but a fundamental component of each part of it. Everyone doing IT must at least be security aware . In this case it would have been enough to use the SHA2 hash algorithm instead of MD5 to prevent the cracking of the passwords.

A new Ransomware kind of attack

Posted on by

This describes a new kind of IT ransom which should be much more professional and profitable.

The attacker manages to access some company’s servers, then encrypts the data in the databases but he modifies the DBs access routines to encrypt/decrypt on the fly all data with his own encryption key. In this way for the company all continues to work. He then waits a few months so that all DB backups are encrypted with his keys and at this point deletes the encryption keys from the company’s systems and asks for a ransom to give it back.Notice that backups are unusable because they too are encrypted with the attacker key.

Obviously, strong IT security procedures should prevent and detect this, from off-line testing of backups to intrusion detection.

IT Security and Cars (and the IoT world)

Posted on by

This news is a very good example of how IT security is generally perceived, almost like an annoying add-on or an after-thought, in any case better to think about it later …

Security should be one of the pillar of any IT product and service but very seldom it is.

It will be very interesting to see how Security and IoT (Internet of Things) will go together, the first glimpses are not promising even if many people warn of the possible disasters ahead.

More Thougths on Maintenance, Updates and Fixing

Posted on by

The issue of maintenance, updates and software fixing actually deserves a few more considerations.

Since a long time, security experts have been saying that software updates are essential for the security of operating systems and applications. A long time ago instead, software updates were considered only when new features or features’ updates were needed. It took a long time but by now, at least for mainstream applications, periodic (eg. daily, weekly, monthly etc.) software updates, in particular for security issues, are standard.

Still there are many unresolved issues. First of all there are still systems which are not updated regularly, among them there are some “mission critical” ICT systems considered so critical that updates are not applied for fear of breaking the system or interrupting the service, and, at the opposite end, some consumer embedded systems considered to be of so little value that a security update feature has been dropped altogether. (In my previous post I briefly mentioned these two classes of systems.)

But there are two other aspects that must be considered. The first one is the time that it takes between the release of the security patch or update by the software vendor or maintainer, and its installation on the system. As in the case of both Bash Shellshock and OpenSSL Heartbleed, patches and updates have been released out of the normal schedule, and they should have been applied “immediately”. To apply “immediately” a patch released out of the normal schedule, one should at least have a way:

  1. to know “immediately” that the patch has been released
  2. to obtain and apply “immediately” the patch to the systems.

Obviously to do this one needs to have some established emergency security procedure in place. One cannot rely on someone reading/hearing the news somewhere and deciding by herself to act as a consequence.

The second aspect, again also relevant in the two incidents mentioned before, is what to do in the time between the announcement of the existence of the bug and the availability of the patch, what is called a 0-day vulnerability. Again there must be some well established emergency security procedure which indicates what to do. The minimum is to assess what is the security risk of running the systems un-patched, to investigate if there are other countermeasures (like signatures for IPS or other network filters, detailed monitoring etc.), and in the extreme case just to turn off the service until the patch is available.

It seems easy, but it is not yet easy to put in practice.