Category Archives: privacy

A Digital Commons

I was just reading Schneiers latest book “Data and Goliath” and was struck by a concept he mentioned: Commons. In the meaning of a digital commons, open and available for anyone to use; not under the control of any specific entity.
Usenet still exists but most online discussions are carried out on (corporate) entity owned websites and platforms. Entities that can and do exercise editorial control.
Anyone who has spent any time in newsgroups on Usenet know full well that it is the “wild west” out there. To the considerable chagrin of some.
A number of academic publishers have banded together to a repository for academic publications and named it (a) Digital Commons.
Not under any ones control and open to all. This satisfies some characteristics of a Common.
But going beyond publication of static documents, what is there. In a common there were many different activities possible: pasturing animals, gathering firewood and food stuffs. Perhaps a digital commons should allow for something more than making static files available to the public. Something interactive, something with some logic – i.e code.

Steganographic applications

Leave a reply

Steganography is the practice of concealing something in something else. For instance hiding a text message inside a larger body of text. There is no cryptography. The security of the message, such as it is, is in the form of obscurity. That may be enough. Cryptography is computational expensive and required management of encryption keys. And it is no more secure that the keys employed. It appears that the better cryptographic algorithms are quite good and attacks tend to focus on the keys.
Attacking steganography would be different. Rather than asking Where is the key, one would ask is there anything there at all ?
There are applications for conducting steganography. Capable of embedding a message inside an image for example. But this is not about conducting steganography.

What I am after here is for application itself to be steganographic. To conceal the application, not inside another application, like a trojan, but altogether.

What would it mean for an application itself to steganographic.

Imagine an application as a book. And using an application as equivalent of reading a book from cover to cover.
Lets further imagine that we cut the the spine of a number of books and shuffle the loose pages together like so many decks of cards. Assuming uniformity of paper quality and page size, layout and font, and no metadata on page – having a loose page tells you little about which book it was from. Or if it came from any book at all.
If you have access to the full text of the original books that were shuffled together, you could do a text comparison and quickly identify which book the page came from. But in the absence of that there would be little to go on. Analyzing the text on the pages would yield some clues and more or less probable guesses could be made. Particularly if the books had comparatively few pages, i.e. if any one page contained a large fraction of the complete text.
The obfuscation could be further improved by cutting the pages up into individual lines of text.
Identifying a line as belonging to only one particular book would be difficult in many cases.

On a side note: what difference does it make cutting the pages up along the lines or across them, for the purposes of putting back together the original page. Again assuming uniformity of paper, layout and font. I venture that a line of text is harder to mach than a column of text. There is a certain balance here. While a line contains more meaningful information, a whole sentence perhaps – it also has fewer markers, fragments of words, that would match it to the strips of paper on either side of it. You gain information in one way and lose it in another. Specifically the anchoring within the larger body.

But the analogy we’re pursuing here is application functionality as reading a complete text: whole book to page to line.

Alright, so we have a large pile of individual strips of paper. Now, how do we read the book?

The premise being that the application, the book in out analogy, is concealed among a large body of code. Where only those knowing exactly what to look for, can find it. The secret in steganography is not the decryption key but how to find what you are looking for – the detection key if you will.
A steganographic application would have to have a detection key. With which you can locate the application and without which you can not. A link to first page, in the book analogy.

In a book you can just turn the pages but here all the pages are separated from one another. How do you get from page to page – or from one line to the next, in the more fine grained analogy.

Each page has a link to the next page but that link is only usable to someone who has a key. Else anyone stumbling on a page would discover the whole book. The idea was that a page does not guarantee a book. Given a pile of pages you can’t know how many books are in it or even if there are any at all. All you have are disjointed pages. Or code.

another Silk Road takedown

Leave a reply

here we go again… The powers that be have take down some evil doers hiding behind TOR. I’m must ask pardon for being a bit jaundiced about the hole thing.
Clearly there are people doing undesirable things taking advantage of the protection offered by TOR. but TOR has a legitimate purpose and the support behind TOR is impeccable. But TOR is not perfect, specifically it is not fool proof. User error compromises it.
But I’m wondering is there is another way for the vendors on Silk Road to conduct their business. Leaving aside the problems of payment for the moment: BitCoin has it’s own weaknesses.
Concentrating merely on how two parties can get in touch with each other. Were A is looking for something that B has to offer, put very generically.

If my understanding of the attack against Silk Road is correct: It is based on having control over a significant portion of the onion routers. Sufficient for being able to establish a pattern of traffic from yourself to a particular .onion address.
Each request packet is routed every which way by the TOR protocol. But with control of enough routing nodes a pattern will never the less emerge since the request packets must eventually end up in the same place: Where the concealed service is hosted.
This last bit is true even without implementation errors. DNS leakage and the like.
What if the hidden service is not hosted in just one particular server, but on many different ones. And using the service will involve traffic to many different locations. Is this possible and whould it make a service concealed behing a onion routing scheme undetectable ?
That depends. If the hidden service is hosted on a fixed set of servers rather than just one, there is no real difference. Just that more traffic now needs to be analysed to be able to pin-point them. This could be counteracted by moving the service often, but that is a defence mechanism independent of how many host the hidden service is using. And controlling more onion routers will help the tracker.

Trusted VPNs is of course an option. Where both the client and the hidden service use VPN to tunnel to some part of the internet. The tracker is then left with finding a proxy rather than the real host. It is still possible that the tracker might use traffic analysis to get from the proxy to the real host. As long as the service stays put long enough.

This suggests a possible course of action. Can the hidden service be dynamically located ? Perhaps even randomly.
I think I’ll work on that. A facinating challenge. Watch this space.

trivial, secure email application, using command line tools

Leave a reply

Demonstrating how to have secure email through the any14.com service.
Using text files and command line tools. Not for the novice users perhaps, simply a demonstration of capabilities.

To start with you download the any14.com code base (SmartServer.war.zip)
Both the sender and the recipient need an addressbook xml file. In here is the information on the other party: name, public key and internet alias. The internet alias should be unique. It doesn’t have to be, for reasons that will be clear further down, but it saves bother if it is.
Both parties also have a properties xml file containing their own information as well as their private key.

The sample file for addressbook for the mail.

The war file is unziped into its own directory. Open a command line prompt, DOS or bash as you prefer, though the sample commands below will be for DOS.

This example is hardly user friendly. It is not meant to be. But put a GUI wrapper around the commands and it is as user friendly as you like. The point is to demonstrate the possibility of sending secure messages over plain HTTP through a generic service like any14.com. The bit about generic is a key point. It is easy enough for the powers that be to block access to more specialized services not used by many people. But the more users a service( i.e. a website) has the less likely is it to be blocked: it has too many necessary functions. More over, and perhaps more significant: using an obscure service might attract attention in certain quarters. Attention that a user might not want. Using a generic service should help the user avoid that attention. Now, of course a generic service mostly won’t offer you what you need – which was why you used the obscure one in the first place. This is where any14.com comes it. It offers the service you program. Any14.com is an on-demand service generator.
In this example we are using the any14.com API locally, having downloaded it from them. And are just passing the messages through their server. We could also have called the API on their server. But the point was also to remove the need of having to trust a remote server. It could be monitored for all we know. In this example the messages are encrypted before they are sent and can not be decrypted by anyone other than the intended recipient. Which is we why are not much bothered about by who might read our messages while they pass through the network and remote systems, and even use plain HTTP.

The SmartServer.war.zip contains sample xml files for a demonstration. There are also two txt files containing the DOS command to be used on Windows. If you prefer bash or another shell on Linux, the modification would be modest.

Both the sender and the recipient have two static xml files: one containing address book information, the other a properties file containing the private information of the party in question such as the user’s private key.

Sender address book, SenderAddressBook.xml

<addressbook>
 <contact name="">
  <name>Recipient Lastname001</name>
  <alias>recipient.lastname001@domain001</alias>
  <internetalias>reallyobscureuseraliasforinternetuse008621</internetalias>
  <publickey>-----BEGIN PUBLIC KEY-----\n
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+8G1x7itnnHGlN0kodreKF7cf\n
e8NWiHk8j/tDD49y4m+jsAbpUh0THj2OWTtQhayswUUG7TW4y4qvONdv3zfIOgz7\n
T5aeBHQCXb8Kk54ffFJC+NYiBwwCR9FhxJzy2AXfJweQFXzYJMh+iz7WLebfrmWi\n
rsHJ4ZPtP4SEW4QRWQIDAQAB\n
-----END PUBLIC KEY-----</publickey>
  </contact>
</addressbook>

Sender properties file, sender.properties.xml

<properties>
  <addressbookfile>SenderAddressBook.xml</addressbookfile>
  <name>Sender Lastname002</name>
  <internetalias>reallyobscureuseraliasforinternetuse005234</internetalias>
  <publickey encoding="none">-----BEGIN PUBLIC KEY-----\n
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+8G1x7itnnHGlN0kodreKF7cf\n
e8NWiHk8j/tDD49y4m+jsAbpUh0THj2OWTtQhayswUUG7TW4y4qvONdv3zfIOgz7\n
T5aeBHQCXb8Kk54ffFJC+NYiBwwCR9FhxJzy2AXfJweQFXzYJMh+iz7WLebfrmWi\n
rsHJ4ZPtP4SEW4QRWQIDAQAB\n
-----END PUBLIC KEY-----
</publickey>
  <privatekey encoding="none">-----BEGIN RSA PRIVATE KEY-----\n
MIICXQIBAAKBgQC+8G1x7itnnHGlN0kodreKF7cfe8NWiHk8j/tDD49y4m+jsAbp\n
Uh0THj2OWTtQhayswUUG7TW4y4qvONdv3zfIOgz7T5aeBHQCXb8Kk54ffFJC+NYi\n
BwwCR9FhxJzy2AXfJweQFXzYJMh+iz7WLebfrmWirsHJ4ZPtP4SEW4QRWQIDAQAB\n
AoGAQlzaDTEUUOyk6yFuAexRGmPnt7+SQu8oBA6e683qs6lT1/aEUG/DvzNRfbox\n
zWjIfTqnPSMQ+utzhjchWbahchIt5QTk2qWIP3zPPaK0eTyvKGrlb65VKkwKfOLx\n
zBWu0wvOzdBnHxx5MlRAYCUa6jlBgIiDsis+GPYtRL7NO8kCQQDoAJpV3aEp/Sdg\n
KkXfdGq47uV9/6dOYcOSYOFU0DwF2M2DXTzFWz/3aUetwMGAzxXkgTKxHvH67FG9\n
evY1hUInAkEA0rB52X2mwkpiAMPJeDxdBO3Ws8DZZotDcCGpWk2c6O+VdvVn2ByQ\n
m1R7vlSPTG0k461vxAua1zWevd7nir3AfwJBAOBKzOqchNXyP6IR3FFm3FKD62x/\n
v8DgdVHLxazYUF8atbz9Y+YtDM9lgf2yL6EXE8RBP7/K+ggrde7otKUTetsCQCcd\n
WlHVcQsrEgzATHwFAOP0X+LZT8Mo4alEppM8S4A3UpFWOCQ4EWS1B5ArVLtEnA+k\n
2FYWLXX8326ynlv0pHMCQQDJwA/yBmYGcJA7qyF1M+VSXDNTg8vwY43kU9LpxfgR\n
sdKpCT7fnyMqj+O84a2gi/X78IBNNR7ZW1t5FIhcRbMn\n
-----END RSA PRIVATE KEY-----</privatekey>

  <localmessagestore>
    <encryption algo="AES" >
      <key encoding="UTF-8">TheBestSecretKey</key>
      <seed>AAAAAAAAAAAAAAAA</seed>
    </encryption>
  </localmessagestore>

</properties>

Recipient address book, RecipientAddressBook.xml

<addressbook>
  <contact name="">
    <name>Sender Lastname002</name>
    <alias>sender.lastname002@domain002</alias>
    <internetalias>reallyobscureuseraliasforinternetuse005234</internetalias>
    <publickey>-----BEGIN PUBLIC KEY-----\n
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+8G1x7itnnHGlN0kodreKF7cf\n
e8NWiHk8j/tDD49y4m+jsAbpUh0THj2OWTtQhayswUUG7TW4y4qvONdv3zfIOgz7\n
T5aeBHQCXb8Kk54ffFJC+NYiBwwCR9FhxJzy2AXfJweQFXzYJMh+iz7WLebfrmWi\n
rsHJ4ZPtP4SEW4QRWQIDAQAB\n
-----END PUBLIC KEY-----</publickey>

  </contact>
</addressbook>

Recipient properties file, recipient.properties.xml

<properties>
  <addressbookfile>C:\SmartServer_war\RecipientAddressBook.xml</addressbookfile>
  <name>Recipient Lastname001</name>
  <internetalias>reallyobscureuseraliasforinternetuse008621</internetalias>


  <publickey encoding="none">-----BEGIN PUBLIC KEY-----\n
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+8G1x7itnnHGlN0kodreKF7cf\n
e8NWiHk8j/tDD49y4m+jsAbpUh0THj2OWTtQhayswUUG7TW4y4qvONdv3zfIOgz7\n
T5aeBHQCXb8Kk54ffFJC+NYiBwwCR9FhxJzy2AXfJweQFXzYJMh+iz7WLebfrmWi\n
rsHJ4ZPtP4SEW4QRWQIDAQAB\n
-----END PUBLIC KEY-----
</publickey>
  <privatekey encoding="none">-----BEGIN RSA PRIVATE KEY-----\n
MIICXQIBAAKBgQC+8G1x7itnnHGlN0kodreKF7cfe8NWiHk8j/tDD49y4m+jsAbp\n
Uh0THj2OWTtQhayswUUG7TW4y4qvONdv3zfIOgz7T5aeBHQCXb8Kk54ffFJC+NYi\n
BwwCR9FhxJzy2AXfJweQFXzYJMh+iz7WLebfrmWirsHJ4ZPtP4SEW4QRWQIDAQAB\n
AoGAQlzaDTEUUOyk6yFuAexRGmPnt7+SQu8oBA6e683qs6lT1/aEUG/DvzNRfbox\n
zWjIfTqnPSMQ+utzhjchWbahchIt5QTk2qWIP3zPPaK0eTyvKGrlb65VKkwKfOLx\n
zBWu0wvOzdBnHxx5MlRAYCUa6jlBgIiDsis+GPYtRL7NO8kCQQDoAJpV3aEp/Sdg\n
KkXfdGq47uV9/6dOYcOSYOFU0DwF2M2DXTzFWz/3aUetwMGAzxXkgTKxHvH67FG9\n
evY1hUInAkEA0rB52X2mwkpiAMPJeDxdBO3Ws8DZZotDcCGpWk2c6O+VdvVn2ByQ\n
m1R7vlSPTG0k461vxAua1zWevd7nir3AfwJBAOBKzOqchNXyP6IR3FFm3FKD62x/\n
v8DgdVHLxazYUF8atbz9Y+YtDM9lgf2yL6EXE8RBP7/K+ggrde7otKUTetsCQCcd\n
WlHVcQsrEgzATHwFAOP0X+LZT8Mo4alEppM8S4A3UpFWOCQ4EWS1B5ArVLtEnA+k\n
2FYWLXX8326ynlv0pHMCQQDJwA/yBmYGcJA7qyF1M+VSXDNTg8vwY43kU9LpxfgR\n
sdKpCT7fnyMqj+O84a2gi/X78IBNNR7ZW1t5FIhcRbMn\n
-----END RSA PRIVATE KEY-----</privatekey>
  <encryptionseed>AAAAAAAAAAAAAAAA</encryptionseed>
</properties>

Sending a message

The flow for sending a message is described here

The individual processing steps follow below. The numbers correspond to those on the graphics.

# step 1
Author the message, enclosed within the ‘text’ tags, in Written.xml
Update the timestamp.
The “to” field must match the alias of an entry in the addressbook. The recipients deliberately obscure internet alias is retrieved from the address book using this alias. The obscure internet alias acts as the recipient email address but it’s uniqueness is not assured, unlike a real email address. But that uniqueness is not really required as only the correct recipient is able to decrypt the message anyway.
The “from” field is populated with the sender’s internet alias kept in the sender.properties.xml

During subsequent steps digital signatures are created and validated. To avoid errors it is best to keep line break characters out of xml documents.

Flatten the Written.xml document using the flatten.xsl stylesheet.

java -cp “WEB-INF\lib\xalan.jar” org.apache.xalan.xslt.Process -IN Written.xml -XSL flatten.xsl -OUT Written_flattened.xml

cat Written_flattened.xml > Written.xml

# step 2
# Apply XSLT to create a smart document.
java -cp “WEB-INF\lib\xalan.jar” org.apache.xalan.xslt.Process -IN Written.xml -XSL Written2Transmitted_sd.xsl -OUT Transmitted_sd.xml

# step 3
# Execute SmartDocument

java -cp “..\build\classes;WEB-INF\lib\servlet-api.jar;WEB-INF\classes;WEB-INF\lib\commons-io-2.4.jar;WEB-INF\lib\commons-codec-1.8.jar” com.any14.smartdoc.SmartDocument Transmitted_sd.xml > Transmitted.xml

# step 4
# Send the message to any14.com

curl -d@Transmitted.xml http://dev-smartserver.elasticbeanstalk.com/

# step 5
# Apply XSLT to sent message to create smartdocument used for creating a secure local copy

java -cp “WEB-INF\lib\xalan.jar” org.apache.xalan.xslt.Process -IN Written.xml -XSL Written2SenderStorable_sd.xsl -OUT SenderStorable_sd.xml

# step 6
# Execute SmartDocument

# step 7
# Apply XSLT to the secure local copy to create smartdocument for reading the sent message

java -cp “WEB-INF\lib\xalan.jar” org.apache.xalan.xslt.Process -IN SenderStorable.xml -XSL SenderStorable2SenderReadable_sd.xsl -OUT SenderReadable_sd.xml

# step 8
# Execute SmartDocument

Receiving a message.

The processing flow for receiving a message is described here

And the individual processing steps follow here.

# step 1
# User retrieves recent message

# URL encode the xpath part
# update the timestamp as required (see Written.xml) to get recent messages

curl http://dev-smartserver.elasticbeanstalk.com/app/smartmessage%5Bto/text()=%27reallyobscureuseraliasforinternetuse008621%27%26timestamp/text()%3E=%272014-07-27%2022:05:00%27%5D > Received.xml

# step 2
# Apply XSLT Received2RecipientStorable_sd.xsl

java -cp “WEB-INF\lib\xalan.jar” org.apache.xalan.xslt.Process -IN Received.xml -XSL Received2RecipientStorable_sd.xsl -OUT RecipientStorable_sd.xml

# step 3

# Execute SmartDocument
# note: this step checks the digital signature. If the file has been on a windows system, there is a good chance that carriage return characters have been introduced , in which case the signature validation may fail because of this.

# step 4
check if message is already in “mail database”, and add it if not.

# step 5 – retrieve a meaasge to read it
# Apply XSLT RecipientStorable2RecipientReadable_sd.xsl

java -cp “WEB-INF\lib\xalan.jar” org.apache.xalan.xslt.Process -IN RecipientStorable.xml -XSL RecipientStorable2RecipientReadable_sd.xsl -OUT RecipientReadable_sd.xml

# step 6
# Execute SmartDocument

computing when you don’t trust the platform

Leave a reply

This appears to be virtually contradiction in terms. In IT security racket we have always stressed the importance of having physical control of the hardware. Anyone with physical access to the device could gain root access to the system and from then on do pretty much anything that wanted.
By extension we could only trust the application, and the safety of our data contained in it, if we also trusted the physical safety of hardware.
The Microsoft verdict is interesting in this regard. If the cloud vendor is US company, a US company own the hardware and it is thus subject to US jurisdiction regardless of there it is located. At the moment we do not know if this verdict will survive a supreme court appeal. But in any eventuality the conundrum remains: Can we have trusted computing on a untrusted computing platform ?

I’m going to try to demonstrate that this is possible for a server application.

Clearly a cloud based web application constructed to work on an untrusted platform would be very different in it’s internal workings from how things are generally done now.
The working model that I propose to pursue will be a web service with thick clients. The web service will run on a cloud vendor subject to US jurisdiction, AWS. I will demonstrate that the sensitive application data will sit on the AWS in encrypted form, at no time be decrypted on the AWS nor have the encryption keys at any point be on the AWS in clear.
The thick client will be an Android app.

In the event that I am successful using a thick client (app), I will attempt the same using a thin client (web browser).

How to secure it on the Internet of Things

Leave a reply

The internet of things is not a new idea but in the hype curve it is now definitely on the upswing. Disillusionment should be setting in soon, before the real delivery of value gets started.

I had an amusing conversation with the CEO of a startup in the business of providing software for monitoring “things” on the Internet of Things. Amusing in that whenever I asked him about how access to these devises was secured, he said that you didn’t access them directly, only a virtual representation. I then followed up with “so they are not connected to the internet then ?” to which he answered yes, they were. I returned to my original question. Repeat. We went though this cycle about 4 or five times. We had a pretty good bit going there; should have taken it on the road. As a CEO of a startup he could have used the money I’m sure. I am also sure that having your security model be a joke on the standup-circuit would perhaps be ill advised.

That still leaves the larger question. What should be security model be for the Internet of Things.

In some sense we have had IoT for a long time already. But the “T” in IoT are not the PCs and servers we are used to. These new devices will not be running a full stack of software. They won’t be able to and even if they were (computing resources gets ever cheaper) it would be hugely wasteful. And a management nightmare too.

Though I’m sure many software vendors will emerge to help us with it. And Microsoft would be perfectly happy to sell a copy of Windows to every fridge and toaster built.

No, these devices will have a simplified software stack. As simple as possible. Requires less hardware, and less is cheaper. Perhaps cheaper by only a few cents, or less, but when you number your devices in the billions, every little bit adds of pretty fast. Simple is also easier to maintain and leaves less room for error (read: bugs).

Considering only the security side of things. What are the minimum security features required ?

Privacy: The devices have to be able communicate privately – which means encryption.

Integrity: The devices have to be able communicate reliably. The data streams must not be tampered with. This ties in with encryption in the TSL/SSL protocols.

Authorization: If the device is able to receive and act on requests , there has to be a way to check the authorization for those requests.

The need to authentication is typically driven by the need for authorization – first you establish who somebody is, then what they are allowed to do – but with PAML tokens this is not so. Authentication is therefore optional, depending on security protocol.

larsreinertsen

The greatest WordPress.com site in all the land!

Category Archives: privacy

A Digital Commons

Steganographic applications

another Silk Road takedown

trivial, secure email application, using command line tools

Sending a message

Receiving a message.

computing when you don’t trust the platform

How to secure it on the Internet of Things