Category Archives: applications on an untrusted cloud

Exploring the issues around cloud provides that can not be trusted and developing working applications that can run securely on an untrusted cloud vendor.

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).

untrusted computing base

Leave a reply

Writing this as Microsoft has lost an appeal against a court ruling that it must hand over data stored in one of it’s overseas data centers to a US authority as stipulated by the search warrant issued by a US court.

This was likely to be the verdict for a while now, and will cause problems for other US based IT cloud vendors hoping to attract business outside the US. Not as much as some may fear, as most consumers of IT services are quite oblivious. But a few, and perhaps much more that a few will have concerns. Possibly decisive ones.

We implicitly trust our IT to do what we want it to, and nothing else. When all of the IT infrastructure was in-house this was easy enough. As more and more of our IT has moved to external vendors or to the cloud this trust has become more explicit. The trust was always there. Malicious insiders is a problem of long standing and moving IT away from the their grasp has reduced the risk they pose, but in exchange for other, less clear, risks. One of those risks has been made apparent by the Microsoft case.: External jurisdictions.

The case of an employee of a Swiss bank who stole information about account holders and sold that information to various countries tax authorities, is a notorious example of how IT insiders can harm the business and extend foreign jurisdictions. That case involved a plethora of criminal behavior, most obviously theft and the buying of stolen property. With the Microsoft verdict the tax authorities can achieve the same results without resorting to enlisting the aid of criminals.

If the bank in question had used an external data center owned or controlled by an entity in a compliant jurisdiction, the tax authorities could have gotten a search warrant against the data center and obtained the desired data; a warrant they would not have been able to obtain against the bank itself.

Clearly the legal waters have been muddied, and only thing that is clear is that we can not trust our computing infrastructure in quite the same way that we have become used to.

larsreinertsen

The greatest WordPress.com site in all the land!

Category Archives: applications on an untrusted cloud

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

untrusted computing base