Category: "Security Engineering"

About the Security Engineering category

  22:47, by Hagai Bar-El   , 49 words
Categories: Security Engineering

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.

Pages: 1 2 4


File Wiping and Disk-on-Key

  21:57, by Hagai Bar-El   , 522 words
Categories: Security Engineering

Most vendors selling security software that deals with removable devices or with flash storage mediums such as Disk-On-Key (DoK) provide the functionality of file wiping (often called shredding) from the removable medium. This feature allows the user to erase sensitive files that are no longer needed, in a way that (presumably) prevents them from ever being recovered; even if forensics gear is involved.

I find file wiping to be a useful function. Software that permanently destroys files is available on PCs since the early 80's and has always been handy. File encryption utilities also use file wiping to remove the original plaintext file after encrypting it.

The one concern I have is about the reliability of these tools when they run against particular files that are stored on flash memory, such as USB DoK or SD cards.

Full story »


Rights Management Systems Versus "Simple" Data Encryption

  21:47, by Hagai Bar-El   , 156 words
Categories: Security Engineering

Here is a question that was raised in a discussion forum, along with my response to it. I figured it is interesting enough to post it here.

Why not just deploy a Enterprise Right Management solution instead of using various encryption tools to prevent data leaks?

The “encryption tools” function according to simple, well understood, and more-or-less enforceable security models. Their assumptions are well understood and, most importantly, match the environments they run on. They solve a simple problem, and solve it effectively.

Rights management solutions have complex security models, and run in environments that do not always satisfy the assumptions. They aim at providing complex functionality, but they often (always?) fail to deliver due to their over-complexity and unrealistic assumptions.

If your security needs can be met by the simple functional model of the “encryption tools”, then you will prefer to enjoy the assurance and thereasonable robustness they provide, which is the most desirable feature after all.


The toughest part of designing secure products

  21:37, by Hagai Bar-El   , 928 words
Categories: Security Engineering

It is already obvious that security is hard to do right. Bruce Schneier has written a good essay called: Why Cryptography Is Harder Than It Looks. This essay refers to cryptography, but touches on the subject as a whole. It is still not always clear, however, where the hard-core of security analysis work is, and where exactly the difference from QA, and from other system engineering domains, lies.

I would like to take a shot at explaining the fundamental difference between assuring functionality and assuring security, and pinpoint the toughest part of security analysis.

Full story »


Watermarking for DRM? Maybe one day

  21:16, by Hagai Bar-El   , 228 words
Categories: Security Engineering

One of the biggest hurdles of DRM results is that content can somehow be leaked by a few skilled individuals and then find itself on the peer-to-peer networks again. The only way to mitigate this threat is by embedding a watermark on the plain content data that will be used either by the playback devices to recognize pirated content or for identifying the source of leaked content on the network.

That's nice, but for this we need a watermarking scheme that can be detected by a non-secret mechanism (called Public Watermarking) and for this mechanism to be such that makes it impossible, or at least very difficult, to peel the mark off. Unfortunately, these two requirements are known to be contradicting. The schemes being public implies that anyone can form an oracle that will tell him as soon as the mark was rendered useless. Once such an oracle is available there is a simple iterative process to be followed by which changes are introduced to and removed from the original content until the result is another piece of content that on one hard is not too different from the original and on the other hand does not contain a usable mark.

This is not to say that watermarking for DRM is doomed to failure - this is just to say that a breakthrough is needed to make it happen.

1 2 4