The Security Engineering category contains articles that discuss analysis of requirements and solutions that are of interest to the security engineer. As opposed to the IT Security category, the articles of this category address not the secure deployment of systems, but the secure design of systems -- software and hardware.
The emergence of the Android Operating System for mobile devices is said to have put the content protection industry in trouble. This is probably true. However, for sake of accuracy, it has not introduced wholly new problems as it worsened existing ones, in an overall situation that was never easy to start with. Let us see what open Operating Systems such as Android have changed, and how the content protection industry may go about to overcome these new-old difficulties.
Cars will soon be (almost) fully automated. News on experiments with cars that drive by themselves, in different scenarios and situations, make it seem obvious that soon enough the role of the driver is to be similar to that of a pilot in a passenger jet. Many people feel some itch of discomfort with this thought; the itch of “we are not there yet”. Let us see if and why we “are not there” yet, and what we can do about it.
No one in the automotive security industry could miss the recently published news article titled “Beware of Hackers Controlling Your Automobile”, published here, and a similar essay titled “Car hackers can kill brakes, engine, and more”, which can be found here. In short, it describes how researchers succeeded in taking over a running car, messing up with its brakes, lights, data systems, and what not.
As alerting and serious as this is, it should not come by as a surprise.
On January 15th, TechWorld published an article called Encryption programs open to kernel hack. Essentially, it warns that the key to encrypted volumes, that is, to volumes of software-encrypted virtual drives, is delivered by the encryption application to the kernel of the operating system, and thus may be captured by a malicious kernel.
“According to a paper [...] such OTFE (on-the-fly-encryption) programs typically pass the password and file path information in the clear to a device driver through a Windows programming function called 'DevicelOControl'.”
And they consider it as a threat:
“Dubbed, the Mount IOCTL (input output control) Attack by Roellgen, an attacker would need to substitute a modified version of the DevicelOControl function that is part of the kernel with one able to log I/O control codes in order to find the one used by an encryption driver. Once found, the plaintext passphrase used to encrypt and decrypt a mounted volume would be vulnerable.”
Such “findings” occur often when the security model of a security system is ignored.
Full-Disk Encryption (FDE) suffers class attacks lately.
As if the latest research (which showed that RAM contents can be recovered after power-down) was not enough, it seems as Firewire ports can form yet an easier attack vector into FDE-locked laptops.
From TechWorld: Windows hacked in seconds via Firewire
The attack takes advantage of the fact that Firewire can directly read and write to a system's memory, adding extra speed to data transfer.
The tool mentioned seems to only bypass the Win32 unlock screen, but given the free access to RAM, exploit code that digs out FDE keys is a matter of very little extra work.
This is nothing new. The concept was presented a couple of years ago, but I haven't seen most FDE enthusiasts disable their Firewire ports yet.
I was interviewed (by e-mail) for a project that preferred to remain undisclosed, on the future of secure content distribution. Enclosed are the (slightly modified) questions and answers.
A while ago the iPhone was hacked so to make it usable on networks other than AT&T's.
Since that moment, many opinions were sounded on how Apple could have done their security better and how the hack could have been eliminated. Moreover, some of the industries security experts went on to their desks to work out a stronger mechanism that can save the gigantic firm from such embarrassments in the future.
An obvious question comes up: couldn't Apple, with its $167 billion market cap, afford to pay some good security designers to protect its assets on the iPhone?