Author Archives: larsrein

accepting PAML tokens

PAML tokens where developed to address the needs of a distributed environment. Providing the ability to make decisions at data access enforcement points without having to contact other parties.
This sounds dandy, but how exactly is it done ?

The high-level process is simple enough.

The devil is luring in the usual place.

The detail here is the digital signature on the resource item in question.
Any data item can be digitally signed, but it the data item is small the signature can be larger than the original data. There is scope for optimization here.
In the PAML token sample the digital signatures are the larger part of the total data. The balance will not be so skewed in more typical examples. But the fact remains that the digital signature in XML documents is very verbose.
This need not be the case where user data is being stored. Assuming the data item is database column with metadata, timestamps and such tings in the other columns. Additional columns can be added to contain only the relevant bits about the signature: Algorithm, Digest, Signature value. This would not take up nearly as much space and would be manageable. For optimization it would be helpful to also store the owners public key (not certificate). This would speed up processioning. When a user’s PAML Token has been accepted and the user’s request has been determined to be permitted by the token, the owners public key is known from the token. This key can be used as a mask on the data, added to SQL statements to further narrow the search in the database and exclude all rows containing data not governed by the PAML token. The user’s request is then applied to the remaining.

Big Personal Data

Reading this article in a Blog on New York Times today I kept thinking about the what was not being said in it. Data governance.
The assumption, not doubt valid, is that ever larger pools of data will be amassed; and suitable analyzed, solutions will be found to existing problems and fantastic new possibilities will emerge.
I don’t doubt the potential in “Big Data” and look forward to its exploitation with interest. But also with some trepidation. With great power come great scope for abuse. This is as true for technology as it is for people. Necessarily so, since it is people how design and use the technology.
The article mentions car sensor data and its collection. But what is this data and who get’s to use it ?
Going on to mention ever higher transfer speeds allowing larger data quantities to exchanged ever faster.

The term Data Lake is used to describe GE accumulation of sensor data. Siting that it permitted speeding up GE’s error detection by a factor of 2000.

With ever larger quantities gathered and ever faster transfer speeds and distributed analytical tools all the worlds data eventually becomes available in a Data Sea, ready for analysis.

The article argues that this is not just technically possible but also both the trend and desirable. The first two are clearly correct. The problems with different data structures and qualities are surmountable. As for whether or not it is desirable the issues are less clear.
That there are advantages to be had is obvious. It is also probable that the advantages are great enough to justify the expense involved. Indeed it would not happen in the commercial world unless there was money to be made. Governments have other objectives, social control including law enforcement, where the expense is not a primary concern, only technical feasibility.

In engineering technical feasibility is a function of resources expended. And the Big Data field is certainly seeing a great deal of resources expended on it, whatever the motivation. So what is possible in future will certainly expand from what is possible today.

Data governance has become a political issue of late. The relentless surveillance by governments of their citizens is becoming more widely known. Not all governments have the resources of the US or the determination of Chinese. But that is a temporary relief. The capabilities will expand and the costs will decline. In due course everyone can aspire to total surveillance.
At present only the richest and most powerful can access the whole data sea. Others can only access the part of it they gathered themselves. This article implies that limitation will fall away and everything will be accessible to those that can pay. But who gets the money? For now it has been those who accumulate the data that get the money. They incur the expenses; servers, storage and bandwidth cost money. The source of the data gets nothing. Certainly no money but in some cases a service. Social media run on expensive server platforms but the user can use them “for free” in exchange with surrendering all their data and any other information the platform can gather about them. Many consider this fair exchange. Even if this is so, it still in the users interest to control where the data is going, who gets to use it and for what. The stories of social media posts that have circulated outside their intended target audience and caused embarrasment are legion. The columnist Kathleen Parker advocated self-sensorship to a degree inconsistent with civilization.
It is unclear whether she honestly meant what she wrote or had simply disengaged her mental faculties before writing the piece. Bill Mahers response was withering and to the point. We can’t live in a world where the only privacy we have is inside our heads. Privacy matters also for those less exalted among us. Scanning social media before a hire is now common practice. And individuals go not get to decide what they need to “hide” – anything that may cause offense or raise the slightest question can cause later inconvenience or worse. Made even more intractable by ever changing social conventions.
Expect to see much, much more on this subject.

Some gatherers of user data have policies in place and tell the user explicitly that while they gather as much data as possible they do not pass it on to any one else. Or if they do, it is in some lesser, anonymized form.

That data is passed along at all suggest convincingly that the data has commercial value. As interconnections improve and data sales increase it is also clear that the source of this data are being underpaid; the data gatherer can increase their revenue per data item without incurring any additional source costs.

Persons who are the source of this data then have both a financial and a data governance issue (read privacy) at stake.

Social media users voluntarily submit to being guinea pigs to marketers. Their data has a clear commercial value and this is what they use to pay for the service.

In due course platforms will appear that also allow users to pay in other forms than just with their own personal information and data they provide themselves. “Pay small monthly fee and we will not sell your emails to your local grocery chain”.
Pay-for-service is available in social media, particularly in the more specialized subsets, like dating, but it is always either a pay or spy business model. Never a commingling of the two on the same platform. This is in most cases driven by technical considerations. It can be tricky to adequately safeguard the user data that is not available for resale. But see

Internet of Things is the next step. How are we going to handle that data. The Big Data providers have the datastore ready to take on the data and the tools to analyze it. But where are the tools to safeguard the individuals ?

trivial, secure email application, using command line tools

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

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 SenderStorable_sd.xml > SenderStorable.xml

# 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

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 SenderReadable_sd.xml > SenderReadable.xml
cat SenderReadable.xml

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.

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 RecipientStorable_sd.xml > RecipientStorable.xml

# 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

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 RecipientReadable_sd.xml > RecipientReadable.xml

computing when you don’t trust the platform

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

The smoke alarm joins the Internet of Things

An inconspicuous example IoT enabled household devices. The smoke alarm.

These things run on batteries and those batteries run out. A little ahead of time they give of an annoying beep to inform you of this. To test them you press a button, to get a beep. So manual acts are required in the field of smoke alarms. It is no secret that this is widely neglected. A great proportion of smoke alarms are sitting without a battery when late night beeping commenced and a fresh battery was not at hand. Some people replace the batteries at the same time every year and so waste both their time and their money.

There are third parties who have an interest in whether or not the smoke alarm in a household are operational. In a multi-family structure the other householders clearly do. The local fire department certainly. Smoke alarms give them an early warning that something might be amiss without necessarily amounting to a full scale alarm. Data analysis over time and many devices will give them data to help identity both false positives and false negatives. Insurance companies most definitely would like to know about smoke alarms. Their policies might be made contingent on alarms being in place and operational. With the money saved split between the parties.

The field of smoke alarms is primed and ready for improvement. Enter the internet of things.

Clearly this tiny device will never have anything other than a limited software stack. Running an LDAP client to authenticate users against a directory server is too far fetched. Yet if the fire department is to be able to probe a whole ecology of WI-FI connected smoke alarms those devices must have a way to verify that the incoming request is authorized. Ideally something stand alone. RESTful; A one-shot request; Stateless. All are desirable qualities.

PAML tokens have the authorization qualities we’re looking for. The user (fire department) establishes an SSL session with the device and the PAML token is thereby established as belonging to the user as well as having been issued by the owner of the device. Using a PAML token implies a both client and server authentication through the cryptographic handshakes that take place, but without having to maintain a list of permitted Certificate Authorities on the device. A very significant practical advantage.

the marble block as a metaphor

Consider the case where the patron has the block already purchased. Perhaps long ago. Trying to find a sculptor willing to undertake the job of making something of it. Clearly the patron would like the largest sculpture possible, using as much of the expensive marble as possible. For marble, read facts. For block, read all the available information and relevant factors.

The marble block can be awkwardly shaped (and facts often are). The larger the sculpture the more or a constraint is the shape of the block. A small paper weight can be freely shaped from a block the size of a car. Any design and shape would be possible of the size if the finished item is much smaller than the starting block. The sculptor is without design constraint if he can chip away as much marble as he likes. (And virtually any position can be defended with impeccable logic if all inconvenient factors can be ignored. )
But if the assignment is for a wild animal perhaps a elephant is a better design choice than a giraffe if the block has the shape of an apple and as much of it as possible should be used. And so the design becomes more constrained.

The David was a masterpiece of making the most of very awkward block of marble – thin and long. Many artists declined to commission when they saw the block the City of Florence had bought for the purpose. Having seen a sketch of it in the Accademia that is easy to understand.

Some time ago I had occasion to read the print version of right-wing online news, debate and discussion forum. The editors had made a selection of the best articles that had appeared on the site. Having never looked at the online version I decided to give them the benefit of the doubt and buy a copy of their “best in show” pieces. It wasn’t bad. The articles I read were well put together and argued. But very narrow. The authors didn’t include much of the “marble”; They had taken David-size blocks of marble and carved beautiful paperweights.

structured debate archtecture – opening statement

For some time it has been clear that online discussion are more laden with personal invective than those that are carried on face-to-face. The causes sited are numerous. A loss of inhibition when not facing the other person; The opportunity to be anonymous and therefore feeling free to went without consequence; Absence of non-verbal communication; More persons not-schooled in the art of the debate entering an arena where before they were excluded by editors.
These all have merit and explanatory power.

But this strand in my blog will not deal with these aspects, but rather consider them as given. Looking for a constructive way forward in the mechanics of the debate itself.

Proposing, designing and building a tool where those participating in the debate themselves execute the steps required to carry on a constructive debate and the tool helps them to do so.

I fully realize that most participants in online debated have no interest in constructive dialog. And indeed may well be incapable of it. For most participants in online discussions the primary purpose is to give them to their feelings with out a second thought, or any thought at all. A cursory examination of any commentary field on any major newspaper will confirm this. Online fora that pretend to seriousness, have been forced to employ editors to curb the worst excesses.

My ambition is that the tool to come of out this design process would make a human editor non-essential. Primarily this will be for the minority who desire to examine an issue constructively and inform themselves of aspects of it they were not already familiar with. Again, learning and trying to both deepen and broaden ones understanding is a minority pursuit. This will be a tool to aid this minority.

PAML token – sample structure

PAML token

<?xml version="1.0"?>
<PAMLToken>
  <requests>
    <request URI="http://localhost:8080/.*" />
    <request URI="http://www.any14.com/.*" />
    <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
      <SignedInfo>
        <CanonicalizationMethod
          Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />
        <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
        <Reference URI="">
          <Transforms>
            <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
          </Transforms>
          <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
          <DigestValue>U67112iFgpYEazS40Oq8oI8BJZM=</DigestValue>
        </Reference>
      </SignedInfo>
      <SignatureValue>JSeXEmGoPtNTt5IzDVHPWQw4w6tM1kYHfb2cIabXoVebKFJp2RHAfYzH/LZYuLQYL+PkdJS4CPtfPFf38ndsiVmjcqD8YJL6/1zjhDYunpnIjKoy92BOvUgEOYIGhXdiqSWtlFy5HaIDsG5FTWzxQzL+kQpclgpnoSNo26oi5Tk=
      </SignatureValue>
      <KeyInfo>
        <KeyValue>
          <RSAKeyValue>
            <Modulus>
              vvBtce4rZ5xxpTdJKHa3ihe3H3vDVoh5PI/7Qw+PcuJvo7AG6VIdEx49jlk7UIWsrMFFBu01uMuKrzjXb983yDoM+0+WngR0Al2/CpOeH3xSQvjWIgcMAkfRYcSc8tgF3ycHkBV82CTIfos+1i3m365loq7ByeGT7T+EhFuEEVk=
            </Modulus>
            <Exponent>AQAB</Exponent>
          </RSAKeyValue>
        </KeyValue>
      </KeyInfo>
    </Signature>
  </requests>
  <Conditions NotOnOrAfter="2108-12-01T03:08:59.000Z"
    NotBefore="2008-01-03T05:00:00.000Z" />
  <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
    <SignedInfo>
      <CanonicalizationMethod
        Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />
      <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
      <Reference URI="">
        <Transforms>
          <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
        </Transforms>
        <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
        <DigestValue>blwGeM5yJYC32cuqFBaaJ5Ha/X0=</DigestValue>
      </Reference>
    </SignedInfo>
    <SignatureValue>mkqSc/jVXh9UVCjaV1nDAnUUZNVR/pJJc8QA6IGZw7mtpBiojG0NAYe5zgLMd9RapI9eJTFDdBtZMh2eCVUySUakTFwx4h8NZXttl0v7D+lZ78Sx2mPSTYTD2gXHL4YBvyNoisHmqBSkx4ukkLhJlCP6J30XSvmHutliYUrk5Uo=
    </SignatureValue>

    <KeyInfo>
      <KeyValue>
        <RSAKeyValue>
          <Modulus>
            vvBtce4rZ5xxpTdJKHa3ihe3H3vDVoh5PI/7Qw+PcuJvo7AG6VIdEx49jlk7UIWsrMFFBu01uMuKrzjXb983yDoM+0+WngR0Al2/CpOeH3xSQvjWIgcMAkfRYcSc8tgF3ycHkBV82CTIfos+1i3m365loq7ByeGT7T+EhFuEEVk=
          </Modulus>
          <Exponent>AQAB</Exponent>
        </RSAKeyValue>
      </KeyValue>
    </KeyInfo>
  </Signature>
</PAMLToken>

How to secure it on the Internet of Things

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.

 

 

Portable Authorization Management Language

This is to follow up on something I wrote earlier about anonymous authorization with tokens.

The token would be in XML structure and be digitally signed. Very similar to SAML tokens in some ways.

The tokens are linked to the resource they grant access to and the user authorized to used them, with two digital signatures, one “on top of” the other. Where the one on top is created by the private key that also signed the resource the token grants access to, and the other one is by the authorized users own private key.

access token exchange process

So much for how the token can be reliably be established as authentic and authoritative.

But what about linking to the request itself. The token is passed along with the request. In the HTTP headers in most cases. The cryptographic handshake established the users authority t use the token. And the user may pass along any number of token along with the request.

But the recipient must also be able to establish that the token(s) govern(s) the request at hand not just that the user is authorized to use it(them)

Inside the token will be more XML and it will follow the conventions of the proposed Portable Authorization Management Language, PAML. These kinds of tokens are therefore named PAML tokens.