Category Archives: IT security

Issues in IT security

Secrecy and IP – There is public, there is private and there is secret.

Leave a reply

If you ask a networking person what a private (IP-)address is, you get one answer: An IP address which is not routable on the internet. There are some IP ranges which have been set aside for use in private networks and won’t work on the internet. For this reason they are sometimes referred to as “non-routable addresses”. Which is why they tend to be used in movies. Type them into your browser and nothing happens. Unless you are in a local network which have routes for them. Emphasis on local. Addresses that start with “10.” and “192.168.” are the most commonly used, and there are a few others as well. Architects tend to think a private address is one that you own.

But what is a public IP address ? That very much depends on who you ask. Network people will say it is it is an address which in not private. An IT architect will say it is an address which is accessible from outside your network. Security would say one which the public can access.

In some sense they are all correct, and that is why the issue is so confused. Because over all of this reigns security. And more particularly secrecy. There are far too many in the IT business who equate security and secrecy. To be sure the two are not opposing concepts for the most part but they intersect only intermittently – and not often. Some think IP security is mainly about secrecy. If the enemy does not know an address, he can’t attack it.

Ah, would that that were so. This is why the difference between public and private is so important. If an architect thinks that a public address is one that other people know about and a private address is one that is secret, the architect might want to keep the address information secret. Only distributed in secure communication; kept in password protected files and in secure document stores etc.

But how secret can an externally accessible IP address really be.

It is illustrative to think in term of physical addresses: A person lives on a secure address. But the house is still there; Numbered sequentially as you like; and the street is public. Anyone can drive to the house at any time. How secure is that? Let’s further suppose that those looking for the occupant of the secure address know that the house has been provided by a company that owns a particular street (public IP range discoverable in DNS). It is a fair guess that the right house is on that street. What does that do to security? If the house is a fortress, it doesn’t matter. But if you base your house security on it being undiscoverable, nothing good.

NAT-ing does nothing useful here. It is like having all your mail sent to the post office and have the post office forward it to your house. Someone can still mail you a remotely detonated bomb (malware). The post office will forward it just the same. (wait a day; trigger it; look for smoke; and you have the right house)

But there is another way: A private road (non-routable/private addresses) cut off from the public road system; you have to be authorized and be lifted in. That is a secure address. Not a full replacement for security at the address of course – you still lock the doors – but the address information is secure as in scanning will not discover it. No looking inside mailboxes on a street you can’t get to.

How to achieve this happy state of affairs. Enter the muddle.

Virtual Private Networks. With “private” here referring both to private addresses as defined above (non-routable) and as in you own it. VPNs are sometimes referred to as encrypted tunnels. Typically based on IPSec but there are other possibilities. Any IP address can be used in a VPN but using a VPN you can have your non-routable “10-dot” address be accessible from anywhere, even over the internet.

And this is done. What strikes me as peculiar is when VPN is used with public/routable addresses. The address is still discoverable, because it is public and no amount of secrecy will change that. The house is on a public street – no matter that the occupant is not listed in the phone book and has his mail sent to the post office. It will be a part of a range that has some other member of it in a public DNS. Therefore it is discoverable through scanning. This is also why services should not run on default ports. And all services running on default port should be disabled as far as possible. Knowing an IP is only half the battle, you still need the right port if you are going to attack something.

Add VPN to the public address and unknown traffic will be prevented from reaching it. Which negates any need to keep it secret – not that you could even if you wanted too. Which leaves no role for secrecy when it comes to IP addresses.

Why even use a public address if you are going to use VPN? They are neither free nor plentiful. Well, you shouldn’t. But if you do, it must be for reasons of convenience. They are unique after all. There is no need to agree a private/non-routable address with the counterparty so as not to cause a conflict with something else in their network. Adding NAT-ing here is just silly as it simply adds confusion and does nothing for security. With one exception: if there is a failure to agree on a single mutually acceptable private address among multiple parties. If there is a hold out, there might have to be NAT-ing between that party and the others.

No, a VPN tunnel should be from one private, non-routable address to another. Not that this needs to be point-to-point. You can route all kinds of traffic though a single VPN tunnel. Your routing tables control that.

Server A has address 10.1.0.10 and sends traffic to Server B at 10.2.0.10 over a VPN. And vice versa. They belong to two separate organization and separate private networks.

The VPN tunnel has openings 10.1.0.1 and 10.2.0.1 respectively. Server A routes traffic bound for 10.2.0.10, to 10.1.0.1. Server B routes traffic bound for 10.1.0.10, to 10.2.0.1.

All of these addresses could be freely published and it would do any external attacker no good at all. Security without secrecy.

Token-in-token, Agent-Principal model of authorization delegation

1 Reply

PAML tokens create portable authorization where the Enforcement point need not know either the Principal making the request or the Owner authorized to grant the request. But the Principal/user must be in direct contact with the enforcement point to establish, through a cryptographic handshake, ownership of the PAML token being used. In many scenarios this direct connection is undesirable, even impossible. The Principal can not have a direct connection to the enforcement point.
A medical records repository is a good example. Security rules prohibit direct access over the internet to such a repository. Intermediary entities, application servers, firewall and the like, are mandated gateways.
In effect someone or something, must act on behalf of the Principal with the Enforcement point: An Agent.

This can be effected by placing one PAML token inside another. This token-in-token functionality is described in detail below. Any number of tokens can be embedded inside one another. In some ways like a certificate chain.
As with a standard Agent-Principal model the Principal trusts the Agent to act in the way the Principal desires. But with PAML token the Principal can narrow the Agents latitude to the extent desired.

Definition of terms

The Principal. This is the person, or entity, on whose behalf the request is undertaken.

Agent. The person or entity carrying out the request task on behalf of the Principal.

Owner. The person or entity that decides if the Principal is entitled to have the request(s) undertaken.

Enforcer. Person or entity in control of the resource and handles the request from the Agent. The Enforcer accepts the PAML token for authorization decisions.

Here is a schematic of the flow

alt text

Agent-Principal use of PAML tokens

 

Explanation of steps
Step 1 Principal prepares a list of request, or logical super-set of requests, in an XML format document; and signs this list with the Principal’s own private key. The logical super-sets can include rules according to which the requests made by the agent should be evaluated. The Agent can only carry out request on this list or ones contained in super-sets on this list. The XML document can include XSLT operations to be applied at enforcement time to the request made by the Agent. With this XSLT the Principal can enforce additional limitations (such as timing or checking token revocation list) on the requests the Agent is making.

Creating (pseudo XML document)

<principal.signature><request.list/></principal.signature>

Using the private key used to sign the request list document and the public key that belong to it: engage in cryptographic handshake with Agent and through this, establish to the Agent’s satisfaction that the Principal is in possession of the private key used to sign the request list.
Pass the signed list to the Agent.

Step 2 Agent attaches own usage conditions to Principal’s signed request.

Creating

<principal.signature><request.list/></principal.signature><agents.usage.conditions/>

And sign with the Agent’s own private key.
Creating

<agent.signature><principal.signature><request.list/></principal.signature><agents.usage.conditions/></agent.signature>

Using the private key used to sign the document and the public key that belong to it: engage in cryptographic handshake with the Owner and through this, establish to the Owner’s satisfaction that the Agent is in possession of the private key used to sign the document.
Pass the signed document to the Owner.

Step 3
Owner attaches own usage conditions to Agent’s signed request.

Creating

<agent.signature><principal.signature><request.list/></principal.signature><agents.usage.conditions/></agent.signature><owners.usage.conditions/>

And sign with the Owners own private key. This is the same private key used to sign the resource the PAML token governs access to.

Creating

<owner.signature><agent.signature><principal.signature><request.list/></principal.signature><agents.usage.conditions/></agent.signature><owners.usage.conditions/></owner.signature>

The PAML token is now completed.
Return the PAML to the Agent.

Step 4
The Agent now has a PAML token providing authorized access to resources signed with the same private key that signed the token. The PAML token can be reused to the limits specified in the owner’s usage conditions. Typically these would at least include validity time periods.
The Agent can now make request to the Enforcer and have them be authorized by the token. The requests are on behalf of the Principal but do not have to be directly from the Principal.

The Agent engages in a cryptographic handshake with the Enforcer using the private key used to sign the document from the Principal and the public key that belong to it: engage in cryptographic handshake with the Enforcer and through this, establish to the Enforcer’s satisfaction that the Agent is in possession of the private key used to create agent signature in the PAML token document.
Passed one or more PAML tokens to the Enforcer.
Pass a request to the Enforcer.

Step 5

The Enforcer examines the PAML tokens it has received. The tokens are checked in the following way and order:
XML validation. Those containing invalid XML are discarded.
XML schema validation. Those containing improper XML are discarded.
Agents signature validation: Using the public key of the Agent established in the cryptographic handshake the agent signature in the token validated. Tokens failing this validation are discarded.
Remaining tokens are tokens the Agent is properly entitled to use.

Examine the request and match it to the request list part of the remaining PAML tokens.
Those token that do not govern the request are discarded. Meaning that the request list in the token(s) do(es) not have at least one match for the request.
The remaining PAML tokens, if any, both belong to the Agent and govern the request the Agent is making.
The Enforcer examines the resource the request is for and what, if any digital signature it bears. Only if the resource bears a signature that can be validated with the same public key that can also validate the owners signature on the PAML token, is the resource considered “in scope” for the request. These two signature validation are carried out using the public key of the owner included with owner’s signature on the PAML token. If both signatures can be successfully validated the request is authorized.

In step 5 we get the desired situation that a completely stand-alone enforcement point can make authorization decisions for agents acting on behalf of someone else, without having to know the identity of either of the parties. This gives obvious benefits in reduced complexity and  ease of deployment.

sailing the data ocean

Leave a reply

What if there was a way for access to data could be authorized everywhere. If you were authorized to access a piece of data you could get access to it wherever it happened to be located.

This is not the way things work at the moment for sure, but if it could be made to work in a convenient way, what should it be like ?

When the first web browser arose some 20+ years ago. Static html pages and other media and document files where available by calling a URL over the HTTP protocol. Security was added – at first pretty coarse grained: If you were logged in you could access pretty much anything. It got better.
Comprehensive tools became available to centrally manage all web access to any document, with the finest granularity. The writing of the rules of who should access to do what, when and where, could be delegated out to those who actually were in a position to know.
But crucially, these tools could only manage access to stuff directly under their control. Often operating in a reverse-proxy mode intercepting HTTP traffic. APIs were available through which other applications could tap into them to take advantage of access control rules contained in them, to do their own authorization. In this way the data under the control of a unified set of access control rules could be made corporate wide. Access to all of a data in a corporation being governed by rules maintained in one place. Everyone would play together in the same data security pool.
In practice this never happened. (re-)Writing applications to take advantage of the API of the chosen security software platform , was too expensive. Other tools emerged to export the security rules from one software platform to another, leaving them to do their own enforcement through their own rule infrastructures. This didn’t work very well because it was too complicated. Rules are fundamentally about meaning, and meaning doesn’t translate easily. Never the less this was an attempt to federate authorization.

Data protected by the same access control rule infrastructure is part of the same pool. A database is a single pool. It has its own internal security governing access to individual pieces of data contained in it, but has no reach outside. The database maintains it’s own list of who gets to access which column in what tables.
A server has it’s own internal arrangement for governing access to the data in its own file systems. It may also have access remote file systems. Some remote file systems would be on other servers, which would govern access (NFS, FTP, Samba etc.) and would therefore not be part of the server’s own pool.

If authorizations could be federated between pools all data would exist in one big virtual pool.
A virtual pool made of multiple physical pools; individual databases, file servers etc. At present this is difficult as there may be user federation between some data pools, but each pool has it’s one authorization, it’s own way to enforce access rules. The rules in one are not known, or directly enforceable in another. There is no federated authorization.

Lets further suppose that any piece of data in this virtual data pool, data ocean really, is accessible over TCP with a URI. The URI may have various formats depending on what type of physical pool is being addressed.
For example, this would be the syntax of an URI accessing a directory (LDAP) store

ldap[s]://hostname:port/base_dn?attributes?scope?filter

And this to access a individual file, using HTTP(S)

https://host:port/path

Access to one of the secure web reverse-proxies mention above, would look like this too.

The would be many others. Note that the username and password does not appear. There would not be any prompting for this information either.
Access control would be through PAML tokens, passed in the headers. A SSL handshake would take place to establish the requesting entity’s authorization for the tokens presented.
All physical pools are defined by the entity that control access to it, and all of these entities, be they LDAP server and file/web server in the URI examples above must be equipped to handle PAML tokens to verify the authorization for the request. Through the acceptance of these PAML token the pools together form a virtual data ocean. Any application can call on data anywhere else and present PAML tokens for authorization.

This leave quite a bit of scope for application architecture. The use of a PAML token require access to the private key of the user to which the PAML token was issued. Which means that if a user is engaged in a transaction with an application and this application needs access to data kept somewhere else on behalf of the user, the application can only present its own PAML token, not forward those it has received from the users. The user must at a minimum contact this other data store directly and engage in a SSL handshake. This way the user’s ownership of the public key is established for the benefit of the data store. The application can then pass the PAML token received from the user on to the data store and the store would now know that the PAML tokens are OK to use; or the user could make the data retrieval directly and pass the data to the application that needs it. Sort of like a data federation.

Note that PAML token are tied to data, not any particular host environment. Among other things this means that the requesting client may send the server a considerable number of tokens in order to establish authorization for all required data. The server will grant the union of all these tokens.

Federated Authorization

Leave a reply

For a while now the use of federated userids has been the norm. A site called the Service Provider, SP, has entered into agreement with another, called the Identity Provider, IP that it will trust the userid the IP sends it as being properly authenticated and accurately identifies the user.
There are a number of way this can be done; the passing of a SAML token from the IP to the SP is a popular way. Where the SAML token contains the userid and the SP trusts this because the token is signed by the IP.

So much for users and their userids, but what about what they have access to; The authorization.
Userids are tied to revenue in significant ways. In businesses deriving revenue from gathering information about the users, the useris is clearly of primary concern. More generally in business applications it is not the userid itself that is central, but what the user has access to and how to execute that access control.

In a standard access control deployment scenario with federated users. For example the user login somewhere else (the IP) and click a link to (return to ) the application in question, with the userid being passed along. This is a federated login. The application (the SP) still examines the userid and refers to its own access control infrastructure for what the user is authorized to do. Could this step be federated too ? Should it ?
Like a login and authentication infrastructure costs money, so does maintaining an access control infrastructure. Federated login cuts the costs of the first, so can Federated Authorization, FA, cut the second.
Form the cost point of view FA makes sense.

Can it be done and does it make sense from a policy and governance point of view ?. It is one thing to let someone else identify the user on your behalf. Digital certificates have been around for a while so the issues surrounding outsourcing the work of identify users are not new. And the risks are largely accepted. But authorization cuts close to the essentials of governance: what are people permitted to do. True, if the user is misidentified having a thorough access control system does not make much difference.
One significant issue is related to changes. A user ID doesn’t change much, if at all. What a user has access to, does. Sometimes great urgency. Having direct control of authorization is then desirable.

The day-to-day problem with access control is not primarily the enforcement, though that can be tricky enough. It is the creation of and updates to policy. The rules governing the access. Who gets to decide and how can those decisions be captured in an enforceable way.

Big Personal Data

Leave a reply

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

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

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

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.

 

 

Portable Authorization Management Language

Leave a reply

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.

portable anonymous authorization tokens

Leave a reply

Is this a contradiction in terms? A token with which you can gain authorized access to data resource without giving your identity ? It sounds a bit fanciful to say the least. And even if it didn’t why would we even want it ?
I suggest that it is not, and that we do; and I’d like to propose, design and develop a technology that makes it possible.

First things first, what precisely do I mean by these terms.

Portable: The user can use the exact same token multiple places. Further, the access control enforcement entity need make no call to an external access control policy store in order to make a decision based on the token.

Anonymous: The token contains no personal information about the user, and the entity receiving the token, using it to establish that the user is indeed authorized to access the resource in question, can not establish the user’s identity with the token. Nor is the users identity needed in order to perform the authorization. Proper ownership of the token is established through PKI and cryptographic handshakes.

Authorization: the token is for authorization only, no authentication. If for granting access to resources the user’s identity is required, it must be established some other way.

Token: it is a piece of data. text or binary, XML or plain text. Opaque or not. Mostly passed in the HTTP headers between client and server in the client-server web model. But other ways should be just as workable, Smart cards for example. Headers have limited size, so HTTP POST must be available. In my proposal I’ll stick with XML as the format of the token. SAML tokens are passed in headers now; this token can be passed in the same way.

A fundamental question is whether or not anonymous authorization is even desirable. How can you maintain authorizations without having a database of your users in order to keep track of who you gave the access to.

And if you have a database of all your users and all the access they have, why not authenticate them and check the database for what access they should have and grant or deny their requests accordingly. No need to have special access tokens. This is how things are done now.

I suggest that this is not very efficient for ultra-large scale or distributed solutions. Every single request to be looked up against a database of access control lists. Granted, those ACL databases can themselves be cloned and distributed out to all access control enforcement points. And this is done. Excellent performance is achievable. At the expense of a complex and elaborate setup.

But it requires all these access enforcement points to be in contact with a central system to get fresh copies of the ACL database. And what about portability ? Will the enforcement point accept ACL databases from multiple sources. This may not make much sense if there data is in one place; Just have the one policy creation point and one user store. But if the data is in multiple locations ? As in a distributed system. Will all of these enforcement points authenticate the user against the same user store and authorize the requests against the same policy store? If you have enough copies of both it can be made to scale, but it is hardly efficient. User federation does not help.

With a truly portable token the enforcement point need make no reference to any other access control policy source to be able authorize or reject the request. There is then no need for high performance user stores and distributed access control policies. This significant. There are far more authorization operations than there are authentication operations. An arrangement where the two are not linked is more robust and scaleable. True, a user should only be authenticated once per session, but that still requires a user store to be available. Even with federation. So a token that can be used without a user database is to be preferred from a performance point of view.

 

NB. This is purely technical examination of these issues. From a business point of view things are quite different: The users identity is a valuable commodity that should be gathered up as much as possible along with whatever action the user takes. The legal aspect is neutral: the user’s request is properly authorized either way.

Here is a high-level view of REST-ful use of a data access token.

Portable access token

portable access token outline of usage.

 

1 User request a token from the data owner. The token can bundle multiple different requests to access data belonging to the owner.

2 Owner grants the token request after approving all the token grants access to. Sending the finished token back to the user.

Note: It makes no difference which party initiates the process of creating the token. At the end both parties have agreed what request are granted by the token, and that is enough. The owner will always have the last word, and can add limitations such as timing without input from the user, but then the user can always decline to use the token.

later

3. send token along with request.

4. check token and check user’s request against the token.

The enforcement point make no reference against a user database or rules database and therefore the token need contain no information directly identifying the user. The token can not be truly anonymous since the user must be able to establish that the user is proper user of the token, but this will not be in the form of a username.