However, I’ve always been concerned about the ease at which new modules are made available and may be integrated into bigger systems.  If I want to create a website that supports QR code generation, for example, as a developer I might do the following:

1. Visit google and search for “nodejs qrcode”.  The first result that comes up is this module - https://github.com/soldair/node-qrcode .  From a brief look at the github page, it seems to do exactly what I want.
2. Download the module locally using ‘npm install qrcode’.  This fetches the module from the npmjs registry and then installs it using the process defined in the package.json file bundled with this module.
3. Test the module to see how it works, probably using the test cases included in the module download.
4. Integrate the module into webinos and then add it to webinos’ package.json file.
5. When the changes make their way into the main project, everyone who downloads and installs webinos will also download and install the qrcode module.

I’m going to go out on a limb and suggest that this is a common way of behaving.  So what risk am I (and anyone developing with nodejs modules) taking?

If you’re using nodejs in production, you’re putting it on a web server.  By necessity, you are also also giving it access to your domain certificates and private keys.  You may also be running nodejs as root (even though this is a bad idea).  As such, that nodejs module (which has full access to your operating system) can steal those keys, access your user database, install further malware and take complete control of your webserver.  It can also take control of the PCs you and your fellow developers use every day.

The targets are juicy and the protection is minimal.

And yet, so far, I have encountered no malware (or at least none that I know about).  Some modules have been reported, apparently, but not many.   Why is that?

It could partly be because the npmjs repository offers a way for malware to be reported and efficiently removed.  Except that it doesn’t.  It may do so informally, but it’s not obvious how one might report malware, and there’s no automatic revocation mechanism or update system for already-deployed modules.

It could be that the source code for most modules is open and therefore malware authors dare not submit malicious modules for fear of being exposed, and those that do rapidly are.  Indeed, in the case of the qrcode module (and most nodejs modules) I can inspect the source code to my heart’s content.  However, the “many eyes” theory of open source security is known to be unreliable and it is unreasonable to suppose that this would provide any level of protection for anything but the most simple of modules.

I can only assume, therefore, that there is little known nodejs malware because the nodejs community are all well-intentioned people.  It may also be because developers who use nodejs modules form a relationship with the developer of the module and therefore establish enough trust to rely on their software.

However, another way of putting it is: nobody has written any yet.

The problem isn’t unique – any third party software could be malicious, not just nodejs modules – but the growing popularity of nodejs makes it a particularly interesting case.  The ease at which modules can be downloaded and used, in combination with their intended target being highly privileged, is cause for concern.

Disagree?  Think that I’ve missed something?  Send me an email – details here.

Like all Android devices, in order to do anything very interesting with it, I have to supply some Google account credentials when setting it up.  And then to play music from the Amazon Cloud, I have to give some Amazon credentials.  And then, likewise, for Facebook, or Skype, or whatever apps you might want to run on the thing.  When cheap devices abound, we are going to have dozens of them in our lives, just for convenience, and need to share accounts and content between them.

But there’s the rub: anyone could build and ship an Android device.  And beside having all the good behaviours baked in, it could also arrange to do bad things with any of those accounts. This is the trusted device problem thrown into sharp relief.  The corporate world has been wrestling with a similar issue under the banner of ‘bring your own device’ for some time now: but plainly it is a consumer problem too.  Whereas I may trust network operators to sell only phones that they can vouch for, the plethora of system-on-a-stick devices which we are surely about to see will occupy a much less well-managed part of the market.

I could use special blank accounts on untrusted devices, but the whole point of having cloud-based services (for want of a better name) is that I can access them from anywhere.  A fresh Google account for the new device would work just fine – but it wouldn’t give me access to all the content, email, and everything else tied to my account.  In fact, the Google account is among the safer things on the new device: thanks to their two-step authentication, stealing the Google password is not enough to provide the keys to the kingdom (though, the authenticator runs on … an Android phone!).

The problem isn’t entirely new, nor purely theoretical: just recently there were news reports of a PC vendor shipping a tainted version of Windows on brand new desktops – and such complexities have concerned the owners of high-value systems for some time.  Management of the supply chain is a big deal when you have real secrets or high-integrity applications.  But in consumer-land, it is quite difficult to explain that you shouldn’t blindly type that all-important password wherever you see a familiar logo: it is fairly difficult to explain that there is scope for something akin to phishing via an attack on a subsystem you cannot even see

Would trusted computing technologies provide a solution?  Well, I suppose they might help: that initial step of registering the new device and the user’s account with the Google servers could contain a remote attestation step, wherein it ‘proves’ that it really is running a good copy of Android.  This might be coupled with some kind of secure boot mandated by a future OS version: you might couple that with trusted virtualization in order to offer safe compartments for valuable applications.

But these things are really quite fraught with complexity (in terms of technology, innovation, liability, network effects, and more) so that I fear their value would be in doubt.  Nevertheless, I don’t really see an alternative on the table at the moment.

You could invent a ‘genuine product’ seal of some kind – a hologram stuck to the product box, perhaps – but who will run that programme, and how much liability will they assume?  You could assume that more locked-down devices are safer – but, reconsidering the supply chain management problem again, how long before we see devices that have been ‘jailbroken’, tained, and re-locked, before being presented through legitimate vendors?

The model is quite badly broken, and a new one is needed. I’d like to hope that the webinos notion of a personal zone (revokable trust among a private cloud of devices) will help: now that the design has matured, the threat model needs revisiting.  The area’s ripe for some more research.

The gist is that Cisco have been upgrading the firmware in Linksys routers so that they can be managed remotely (under the user’s control, normally) from Cisco’s cloud.  The impact of this is hotly debated, and I think Cisco disputes the conclusions reached by the journalists at Extreme Tech.  Certainly there’s a diffusion of control, a likelihood of future automatic updates, and various content restrictions (against, for example, using the service – whatever that entails – for “obscene, pornographic, or offensive purposes”, things which are generally lawful), and a general diminution of privacy.

Some commentators have reacted by suggesting buying different products (fair enough, depending on where the market leads), ‘downgrading’ to older firmware (not a long-term solution, given the onward march of vulnerability discovery),  or flashing one’s own firmware from some open source router development project (this is a surprisingly fertile area).  To someone interested in trusted computing and secure boot, the latter is quite interesting – you can do it now, but can/should you be able to in the future?

One of the central themes of some of the stuff around secure boot is that we want cryptographically-strong ways to choose which software is and is not booted, and leave this choice well away from the users, because they can’t be trusted to make the right decision.  That’s not some patronizing comment about the uneducated or unaware – I’d apply it to myself.  (I speak as someone who hasn’t knowingly encountered a Windows virus/trojan/work in decades despite using Windows daily: I think my online behaviour is fairly safe, but I am under no illusions about how easy it would be to become a victim.)  Whilst there are good reasons to want to retain a general power to program something like a PC to do whatsoever I wish, I can imagine that the majority of internet-connected devices in the future will be really quite tightly locked-down.  And this, in general, seems a good thing. I don’t demand to be able to re-program my washing machine, and I shouldn’t be able to demand to re-program my digital photo frame, or even my TV set-top box.

However, whereas my washing machine has no immediate prospect of connection to the internet (though the smart grid could change all that), many other devices are connected – and their mis-design will compromise my privacy or my data’s integrity, or worse.  And, indeed, involuntary remote updates could break them or reduce their functionality (a mess that already exists, and is really not well-addressed by consumer protection legislation).  I might have a reasonably secure household of internet junk until some over-eager product manager decides to improve one of my devices overnight one day. I could wake to find that my household had seized up and all my privacy gone, if the attacker followed the locus of the product updates.  This really isn’t particularly far-fetched.

So, I am faced with a tension.  A paradox, almost.  I am not well-placed to make security decisions by myself; none of us is, especially when we don’t even realise the decisions we are making are security-related.  But in this complex advertising-driven world, those to whom I am likely to delegate (perhaps involuntarily) such decisions are (a) themselves imperfect, and much more worryingly (b) highly motivated to monetize my relationship with them in every way possible.  Goodbye privacy.

The market might help to remedy the worst excesses in these relationships,  but when its dominated by large vendors suing each other over imagined patent infringements, I’m not optimistic about it resolving this tension in a timely manner.

Regulation could be a solution, but is seldom timely and often regulates the wrong thing (as the current mess of cookie regulation in the EU amply demonstrates).

Perhaps there is a role for third-party, not-for-profit agencies which help to regulate the deployment of security and privacy-related technologies – receiving delegated control of a variety of authorization decisions, for example, to save you from wondering if you want App X to be allowed to do Y.  They could in principle represent consumer power and hold the ring against both the vendors who want to make the user into the product and the attackers whose motives are simpler.  But will we build technologies in such a way as to permit the rise of such agencies?  It will take a concerted effort, I think.

Any other ideas?

The aim of the scheme is to promote original research which helps to advance the state of the art: this means both getting such research done in the UK, and developing a pool of expertise for academia, government, and business.  Wise and talented individuals are clearly crucial, and it’s a privilege to work with a large such group in Oxford.

The scheme is modelled after one which has been running in the USA for some time, fronted by the NSA.  Their programme is extensive, and has other components – such as Centres of Excellence in Education, which we might expect to see here in the fullness of time.

Is close association with GCHQ a double-edged sword?  They host the national technical authority for information assurance and so have a good idea of the kind of research which may be useful.  In principle, they also have deep pockets (though not nearly as deep as those of their American counterparts mentioned above).  On the other hand, universities will not stay excellent for very long if they are (or are seen to be) the patsies of the state.  Happily, I think this is recognised by all sides, and we can look forward to some creative tension made possible precisely because our research is “outside the fence”.

There’s an interesting clash of mind-sets to hold in mind, too:  the University is an open and exceptionally international place.  Security research is pursued by people who have not just diverse skills but also a variety of affiliations and loyalties – in contrast to those who work in security for the State, who must generally be citizens or otherwise able to hold an advanced clearance. Having the one inform the other sets up tensions – all the more so if there is to be two-way flow of ideas.  Perhaps an interesting topic of research for those in social sciences would be to ask what a “clearance” might look like in the cyber domain – if not based on citizenship, what might be the baseline for assuming shared objectives?

That is one of many cases which show that the concerns of Cyber Security clearly spread beyond the technical domain in which they first arise. Inter-disciplinary study is essential for the future of this topic.  The next blog post will reproduce an article I recently wrote on the subject.

We’ve been referring to these patterns throughout the webinos project when designing the system and security architecture.  However, it’s interesting to note that the web (and web applications) actually directly contradict many of them.  Does this make the web insecure?  Or does it suggest that the patterns and principles are inadequate?  Either way, in this blog post I’m going to explore the relationship between some of these principles and the web.

I’m going to skip some of the principles, and focus on just the most relevant.

Install before Execute

Ensure that programs cannot run unless they have been properly installed.

This pattern is clearly broken on the web.  Visiting a webpage does not install anything, but does allow a web application to run.  The sandbox model of webpages, however, protects against a malicious web application.  What it doesn’t do in practice is protect against phishing sites, clickjacking or other web-based attacks.  Furthermore, access to privacy-sensitive APIs such as Geolocation require approval but no explicit installation.

Explicit User Audit

Allow the user to inspect all user-generated information
stored in the system to see if information is present and
verify that it is accurate. There should be no hidden data.

This principle varies on different sites, but is rarely adhered to.  Google and Facebook, to their credit, allow users to download and inspect most of the data held about them.  However, these are the exceptions rather than the rule.  Hidden data is very much the norm.

Complete Delete

Ensure that when the user deletes the visible repre- sentation of something, the hidden representations are deleted as well.

While this is theoretically something that a web application could do, it is very rare to see it.  Social networks have started to provide full account deletion as an option, but only as a result of user requests and news articles.

Leverage Existing Identification

Use existing identification schemes, rather than trying to create new ones.

This is definitely getting better.  The rise of OpenID and single-sign-on means that more websites allow users to be identified by existing accounts rather than recreating their identity for each application.

Email-Based Identification and Authentication

Use the ability to receive mail at a pre-determined email address to establish one’s identity or authorization to modify account parameters.

This is the standard way of recovering credentials and authorising privileged actions on the web.  However, one might question the wisdom of this. As email is itself being served by web applications and account hijacking is extremely common, this seems like poor protection.  This explains why text messages and smartcards are being used by the likes of PayPal to recover credentials.  However, this may also not be enough.

Key Continuity Management

Use digital certificates that are self-signed or signed by unknown CAs for some purpose that furthers secure usa- bility, rather than ignoring them entirely. This, in turns, makes possible the use of automatically created self- signed certificates created by individuals or organiza- tions that are unable or unwilling to obtain certificates from well-known Certification Authorities.

This is very rarely the case on the web – either a website has a certificate with a root in your browser, or you will receive so many security warnings that most people won’t use it.  Most browsers do allow you to add self-signed keys to the list of trusted authorities, but I expect this to be rarely used outside of corporate environments.

Disclose Significant Deviations

Inform the user when an object (software or physical) is likely to behave in a manner that is significantly different than expected. Ideally the disclosure should be made by the object’s creator.

Arguably web applications do this when they break the browser sandbox – to access device features – by presenting a dialogue or pop-up prompt for confirmation.

Distinguish Between Run and Open

Distinguish the act of running a program from the open- ing of a data file.

This is certainly not the case on the web.  While it should be possible (using content-type headers) to force a browser to display text, it is rarely used in practice.  Visiting a web application and reading a page of text have exactly the same security framework around them.

Disable by Default

Ensure that systems does not enable services, servers, and other significant but potentially surprising and security-relevant functionality unless there is a need to do so.

Browsers are a good example of this.  The sandbox that websites run within is a default-deny environment which requires explicit consent before dangerous activities can occur.  Of course, this may not be true of the web server or cloud-based content.

Warn When Unsafe and Distinguish Security Levels

Periodically warn of unsafe configurations or actions.

Give the user a simple way to distinguish between simi- lar operations that are more-secure and less-secure. The visual indications should be consistent across products, packages and vendors.

This is partially followed with HTTP/HTTPS status.  When a website has an invalid certificate, the user is warned constantly by an icon on the address bar.  However, little attention is drawn towards an HTTP connection.  Other enabled features such as Geolocation may have icons showing that they are active on a page, but this is not necessarily safe or unsafe.

Conclusion?

Overall, the web and browsers in particular are guilty of violating these principles.  In some cases, this is due to the sandbox enforced by the browser.  However, the migration of web pages from static text to dynamic, potentially untrustworthy applications, means that principles such as Install Before Execute and Distinguish Between Run and Open may become more relevant.   Reintroducing them for offline web applications and widgets may be a good idea, or might confuse users further.

In that blog post, Joseph Bonneau proposes an alternative one-liner:

A really strong password is one that nobody else has ever used.

(One of the commentors (J. Carlio) suggests modifications to add something about memorability. )

This is a seductive idea: it is, broadly, true.  It encapsulates the idea that you are trying to defeat brute force attacks, and that these generally succeed by attempting plausible passwords.

But I don’t think it’s good advice.    That is mainly because many people are poor with estimates that surround very large numbers: whether the likelihood of my password being used by someone else is one in a thousand, one in a million, one in a trillion (the word of the week, thanks to national debts) is something that, I would say, few people have a good intuition about.  In just the same way, people are poor at risk assessment for unlikely events.

It’s also insufficient because someone following this advice will tend to under-estimate the power of brute force search: if you are a player of the National Lottery, you choose some numbers at random, and hope that no one else will choose the same numbers (so that if you win, you do not have to share the prize).  But the very act of playing the lottery, still less the heuristics people use for choosing ‘unlikely’ combinations, show many up as being poor with these kinds of estimates.  A string consisting of your favourite lottery numbers would of course be quite a poor password (though just how poor depends a great deal on your attacker assumptions).

I’m reminded of a fairly recent letter to a national newspaper, where the correspondent reported that his habitual password was his former National Service Army Number (which was, I think, some 6-8 digits, perhaps with a letter or two).  He reasoned that this was unique, unlikely to be available to anyone else, and, at this remove from national service days, unlikely to be recorded in any accessible place. All of these assumptions are doubtful, and all the more so after his letter was published – even though he clearly imagined that he had made a password which precisely matched Bonneau’s prescription.

All of this sounds like a rather familiar lesson from usable security, albeit in a new guise.  Back to square one on password advice.

The blog is set up so that individuals from within the group can post using their Oxford credentials. Others can post comments, but the first time they comment, the comment must be moderated.

Some try posting their adverts for herbal remedies right away. Those are easy to spot and throw away.

There are several, though, who have posted comments like “I like this blog. You make good points.” I assume that the aim of these is that they are likely to get approved by a semi-vigilant moderator because then the commenter becomes a trusted poster.  Presumably, the advertising spam would follow thereafter.

I remark on this

• (a) because other members of the group may moderate comments, and should be on the lookout for this ‘trojan’ behaviour;
• (b) because it points to a greater degree of tenacity on the part of the spammers than I would have realised existed;
• (c) because it seems a particularly hard problem to solve, CAPTCHAs notwithstanding.

As a brief recap: the webinos project aims to design and deliver an open source web runtime for four types of device: smartphones, media centres, PCs and in-car computers.  It will provide a set of standard JavaScript APIs for accessing device features from web applications, as well as synchronising data and providing a “seamless” end user experience.  We’re working on it with over 20 other companies and are primarily researching the security and privacy aspects of the system.  More details are available on our website: http://www.cs.ox.ac.uk/projects/webinos/

In webinos we think we have (at least) the following data to protect:

• Application data.  Web applications can store data using HTML5 web storage.  While we can’t be sure what each application will store, following a “secure by default” principle would imply that we encrypt all application data unless told otherwise.  In some scenarios, there may be performance reasons why this is not a good idea.
• XACML access control policy rule files.  Webinos access control is managed through XACML policies, stored as files on the system. The biggest threat is that these could be modified to grant a malicious party access to device capabilities.  In addition, they may be confidential, too, for privacy reasons.  One might be uncomfortable with the whole world knowing who you’ve given access to your home computer to, for example.  This is perhaps of secondary importance to integrity.
• Credentials.  The webinos platform (and webinos applications) want to access online services.  Doing so requires credentials, and webinos (like a browser) will need to save some of these credentials to avoid tedious re-entry of usernames and passwords.  The confidentiality of these stored credentials is paramount.
• Lists of trusted (and untrusted) user identities.  Much like policies, user identities must be protected from modification (an application should not be able to replace Bob’s public key with Ivan’s) but are also private.  Revealing trust relations may violate user privacy expectations
• Context data.  This is perhaps the most interesting.  The webinos platform will (optionally) collect information about what actions you have performed, what applications you have used, and your wider environment.  This is intended to enhance the user experience, but will also result in a large amount of private information which must remain confidential.  The challenge with context data is that it must be stored rapidly and searched quickly, or it becomes significantly less useful.  Encryption of this data is likely to add an unreasonable performance and battery-life cost.

Given this range of objects to protect, what specific attacks are we most worried about?  For one, we want to protect end users should they lose their devices or have them stolen.  A thief (perhaps part of a larger organised crime syndicate) should not be able to access user data or perform subsequent identity theft or social engineering based attacks.  On some operating systems we might get this for free, but on others we do not.  Another concern is malware: should a malicious application run on webinos (or on the OS hosting webinos) it should not gain access to user data or credentials.  Encrypted storage may not be enough here: key management and authentication is necessary.  Finally, we have to worry about recovery of encrypted data should passwords or keys be lost, backups, and migration of data between devices.

As well as security requirements, we have some technical ones.  Whatever solution we come up with, it has to work across all devices, and it would make sense for encrypted data items to be portable.  As mentioned earlier, performance on mobile devices is also particularly important, as encryption can have a big impact on battery life.  The project is also limited in what it can do: it can’t control the operations system or insist that every device has a secure token or TPM installed.  As no cross-platform, portable secure storage solution currently exists, these technical challenges are clearly significant.

There are a number of implementation options, and NIST have published an overview of recommendations for secure storage on end user devices, which go through the main alternatives.  Full disk encryption, where every file is protected either through a self-encrypting drive or some pre-boot software; virtual disk encryption; volume encryption; and individual file/folder encryption.  Inevitably, a hybrid is required for webinos.  Full disk encryption does not provide much protection against malware, and is unlikely to exist on every device.  Volume encryption also tends to be platform specific, and is unlikely to prevent against malware.  Virtual disk encryption (where a filesystem is encrypted into a single encrypted file) can be more portable, but can have poor performance.  File/folder encryption may allow for more selective policies on encryption, but is also harder to make available to all parts of the system.

For webinos, we probably want a mixture of options, but cross-platform requirements limit what is practical.  Where available, we intend to take advantage of existing device capabilities, such as key storage (e.g. the Android KeyStore), secure elements and encrypted drives.  However, each device category has a slightly different protection profile.  Mobile operating systems seem to do a good job of isolating applications and storage, making malware less of an issue.  Add to this the fact that mobile devices are more prone to theft and loss, and an encrypted drive seems like the best solution, assuming the performance is adequate.  On PC, application-specific encryption might work best to protect data from malware, as OS level application-specific access control rules are seldom implemented.  Home media centres and cars may have different requirements altogether.  What is abundantly clear is that what started out as a fairly simple requirement — protect data at rest — has become a significant challenge already, and that’s before backups and recovery are considered.

The savvy reader will note that what I haven’t done in this post is explain what webinos will do to protect its storage.  That’s because the final result will inevitably require testing for performance and usability, and will be affected by technical constraints, such as the platform capabilities currently available.  Ultimately, this post does not have many answers, but has hopefully highlighted some of the issues in cross-platform secure storage, as well as providing an insight into the issues currently facing webinos researchers.

I suppose I have two reasons for doing this:

• trawling the archives is occasionally useful (for finding information, or confirming what someone said, or being reminded what I said); because just about all of my work is eventually mediated (in and out) by email, the mailbox archive plays the role of a professional journal.
• the process of filing and deciding what to retain and what to delete is insanely time-consuming, and easily costs more than the now insanely cheap cost of disc storage and associated backups.