No more ATM BSOD.
Wait- I hear torches and pitchforks and drooling approaching!
Banks have a new option for finally unhitching from Windows XP on tens of thousands of ATMs – Google’s Android. NCR, the country’s largest supplier of cash machines, was today due to unveil a Linux-powered cash-machine running Google’s smartphone operating system. Called Kalpana*, NCR has developed a secure, customised version …
"NCR has deveped a secure, customised version of Android KitKat 4.4.4"
LOL @ Android and secure in the same sentence.
"NCR claimed that an “average” cash-only dispenser costs $20,000 a year to maintain but Kalpana would cost between $12,000 and $15,000. Other cost savings will be passed on to the banks in terms of not having to pay a Microsoft licensing fee for Windows on each cash machine they operate."
Because a circa $200 license fee to cover say 5 years life is such a large cost versus $15K a year. Not.
"LOL @ Android and secure in the same sentence."
As I recall, there was no hide or hair mentioned of the Android application framework, only the Linux core behind that framework, which last I checked is still pretty tight. The last vulnerability I could pick up came from the baseline Linux kernel, not from anything Google did to it, and that's since been fixed.
IOW, perhaps the article's rather misnamed as the new OS is closer to Chrome OS (a web-based thin client) than Android.
"only the Linux core behind that framework, which last I checked is still pretty tight. The last vulnerability I could pick up came from the baseline Linux kernel"
The Linux kernel alone had more vulnerabilities in the last year than a whole current Windows OS did...Plus you have whatever Google broke.
The Linux kernel has had a tiny handful of vulnerabilities in its whole life. That a few brain damaged "security" sites claim all vulnerabilities for software that comes bundled in a Linux distro is a vulnerability in the "Linux kernel" shows how ignorant people who post on the Reg come to ignorant incorrect conclusions.
If Windows shipped with as much software as a typical Linux distribution did, it would have a lot more vulnerabilities. Vulnerabilities in Office don't count against Windows, but vulnerabilities in LibreOffice are counted against Linux since all distros ship with it. And a few dumb security sites unworthy of the name claim those to be vulnerabilities in the Linux kernel.
Also, many sites separately count vulnerabilities in Red Hat, Fedora, Ubuntu, etc. so one Linux vulnerability counts against it a bunch of times. But somehow the same 'courtesy' isn't extended to Windows Vista, 7, 8, 8.1, Server 2008, Server 2013 and so forth when a single vulnerability affects them all.
It is ironic that this guy makes the claim Windows has fewer vulnerabilities while I'm currently updating my Windows VM that was last updated Feb. 28th and I see around a dozen "Security Update" listed - and I'm not even sure this includes April since the image is corporate managed and may not have pushed out the April updates yet!
"The Linux kernel has had a tiny handful of vulnerabilities in its whole life. That a few brain damaged "security" sites claim all vulnerabilities for software that comes bundled in a Linux distro is a vulnerability in the "Linux kernel" shows how ignorant people who post on the Reg come to ignorant incorrect conclusions."
Nope, it's you that are ignorant:
Since it's all Linux kernel vulnerabilities (all versions according to the link you provided), I thought I'd do a comparison to all Windows vulnerabilities (all versions, just to have a valid comparison). Of course,we can only compare the last three years, 2013-present, as that is only as long as Windows 8.1 statistics go from your website of choice.
Linux: 189 + 133 + 25 = 347 total vulnerabilities for all versions of the Linux kernel since 2013, supported or otherwise.
Windows is a bit more difficult as there are multiple versions listed separately.
Desktop Windows (7, 8, 8.1) = 165 + 112 + 120 = 397 vulnerabilities.
Windows Server (2008, 2012) = 155 + 76 + 85 = 316 vulnerabilities.
This is a total of 713 vulnerabilities for all currently supported versions of Windows.
I'm being lenient for Windows here as I'm only including current versions of Windows whereas ALL versions of Linux kernel are lumped together, not just the current versions. I have not included versions of Windows that are still used widely but are no longer receiving security updates: Windows XP, Vista and Server 2003. (This would add another 420 vulnerabilities for a total of 1133)
So while you are correct in stating that there are more than a handful of Linux kernel vulnerabilities, there are far more Windows vulnerabilities; and that is only the vulnerabilities that Microsoft tells us about.
Windows 8 and 8.1 are both Windows 8. It's the new 'Service Pack' format. Not to mention that most vulnerabilities will apply to all supported versions and are not unique so you are likely over counting for Windows by a factor of 5...
"whereas ALL versions of Linux kernel are lumped together"
No - these are unique Linux kernel vulnerabilities. If you drill down you will see that the same issue in multiple versions is only counted once.
"So while you are correct in stating that there are more than a handful of Linux kernel vulnerabilities, there are far more Windows vulnerabilities"
Not in the last year (e,g. during all of 2014) - as was stated! The Linux kernel alone had more holes than the whole Windows OS did.
Stating it again doesn't make it so. Like I pointed out last you made this ignorant comment, actually read what you post. Look at the 2015 link, and notice how many of those vulnerabilities involve Chrome. Unless you are braindead enough to believe Chrome is part of the kernel, you will realize your lie has been exposed.
That link is titled Linux kernel vulnerabilities and shows a bunch of Chrome vulnerabilities. So you're wrong there.
Also, most of the rest is driver related. An Infiniband exploit is not a kernel vulnerability, the only way that module can run is if that hardware is installed and the driver is loaded.
"The Linux kernel alone had more vulnerabilities in the last year than a whole current Windows OS did..."
This is no doubt based on that nonsense article where they added up all the vulnerabilities reported in every version of the Linux kernel still being maintained (which can't help but count some vulnerabilites multiple times when they are in more than one version of the kernel besides counting vulnerabilities that never occur on the same system because they are not in the same kernel) and compared the number to the reported vulnerabilities in one version of Windows. Of course there are plenty more points to discuss about the statistics actually published by the NVD, but that article was so much nonsense from a third party, GFI, and was even updated in response to criticisms, though still not made one hundred percent clear.
As I recall, there was no hide or hair mentioned of the Android application framework, only the Linux core behind that framework, which last I checked is still pretty tight.
Indeed. What was mentioned, though, was this:
"Kalpana apps are Webbified; built using HTML rather than using Microsoft-friendly tools and language. They are served to a WebKit-based UI from a back-end in a bank’s data centre, constructed using the Spring Framework and RESTful APIs."
If I understand this correctly, this means that ATMs will run browser-based apps (I tried looking up Kalpana, but had little luck). I can see where this might be appealing from a development point of view (easy to get people who can do this sort of thing and would speed development and deployment cycles), but not from a security perspective. For example, what happens if an ATM is cut off from phoning home? The answer to this question can dramatically affect how hackable one of these machines is. Even assuming that using a web app is the cool thing to do, why not use a microkernel OS rather than Android?
NCR picked Android, it said, because this offered the clearest roadmap in Linux with support from Google – it evaluated Red Hat, CentOS and building its own, too.
Not sure what this "clearest roadmap" means. What's a example of thing that would be easier on Android than Red Hat? Security updates?
For security reasons, I'd want to have the cameras on a separate data and control channel, so that if somebody does manage to hack the ATM, they don't also gain control to the camera. And it's still relatively straightforward to associate the video stream with the ATM activity, should you need to retrieve and compare, say by time-stamping both.
"Extended Support for Windows XP Embedded at the supported service pack level is available until January 12, 2016" [Source: http://blogs.msdn.com/b/windows-embedded/archive/2011/02/17/support-lifecycle-transitions-for-windows-xp-embedded.aspx ]
So actually given the size of the deployment (ie. number of ATMs and their geographic distribution), it is actually very late in the day to be announcing a new platform OS that is to replace XP. But if NCR are guaranteeing that it will run on all their existing NCR ATM's and so they can effectively updated overnight they might get some customers committing to it.
Perfect application for Linux, no just the Kernel. I would say that one of the main reason android was chosen over plain linux is the inclusion of components like Binder, ashmem, pmem, logger, wakelocks.
Another area they may have hound attractive is the The flash storage and the way that android is trying to prevent apps writing to other apps storage area.
Android's default user interface would have also been very attractive to NCR, as it is based on direct manipulation, using touch inputs, that loosely correspond to real-world actions, like swiping, tapping, pinching, and reverse pinching to manipulate on-screen objects, and a virtual keyboard.
The android power saving & wireless stack may also be of interest as this could make it easier to site ATM's in remote locations where it is hard to provide electricity and broadband/modem connections.
I have worked with NCR's past offerings and this will be a dream in comparison, especially for small financial institutions and those in the middle east, Africa and Asia.
Another key bit: "security with a secure boot-loader used to validate the kernel and operating system and prevent hackers booting code not signed by NCR"
That's what Chrome OS already does (when run in Kiosk mode, which is ideal for ATMs as well as hotel front desks, restaurant tills etc). And for banks there's Chromium OS so they don't need to depend on Google for updates (or have them pushed by Google).
As much as I like Android, if "Kalpana apps are Webbified – built using HTML rather than using Microsoft-friendly tools and language" then the best OS would be something like Chromuim OS, Firefox OS or WebOS.
The question they asked is exactly correct - given all that we know, all the open-source frameworks available, could we make an application run without Windows?
The answer or course is yes. Most companies started down the Windows road in the '90's because it was the easiest way to get a graphical application up and running quickly. At that time the alternative was a grueling full stack development process.
But now, HTML5 lets you create any graphical application imaginable, including 3D.. and there are plenty of really nice open source operating systems, frameworks and databases that let you snap together powerful technology stacks quickly. There is no excuse for running windows anymore, especially for business critical tasks.
" Not convinced, there should be no need to use FAT, interface to MS-Exchange or run Microsoft compatible applications"
Microsoft cites over 200 patents as applicable to Android. Nokia and Apple also claim quite a few. Even if a few are invalidated, the balance of probability is that there are plenty of valid ones that will stick...
"Why didn't NCR use CentOS/Redhat or Debian, Why Android, it only of benefit for portable devices running Google's clone of Java for Apps. This is only going to have NCR's application."
As for CentOS/RHEL 6, they're going to be supported for another 5 years (I think). You can bet that a lot (all?) of these ATMs are not 64-bit, and RHEL7 doesn't do 32-bit. Additionally, I'm not sure how well Linux+X+touch drivers+browser fits onto the old Intel-based hardware that's (probably) inside these machines. My guess is these are low-end spec PCs from the 2004-ish era. Debian probably has a 32-bit, I'm not as familar with their road-map. Android would seem to make a lot of sense, it's designed around touch interfaces and lower-power hardware, and has a hardware-upgrade path into low-power ARM if so desired. The security issues are almost always due to apps, which doesn't really apply to an ATM.
As for Windows upgrade to 8.1: there's no way in hell they'd do an upgrade in PC terms as one poster suggested. The ATMs would be re-imaged with embedded 8.1 and whatever small amount of configuration done. (I don't have any experience with these machines, but I can't imagine there's much more to the individual location config than location, phone number to dial, etc.)
so, they upgrade from xp embedded to 8.1 embedded a known upgrade path, probably able to re-use much of the old hardware... the software will either run natively or require massaging to run on the newer os... and this is more expensive than...
re-certifying a totally new OS and rewriting all the software from scratch?
all to save possibly £20-£40 per machine for a windows licence?
each to their own... whatever the driving force behind this move, it wont make a huge amount of difference the cash withdrawl experience, but someone somewhere has had a nice holiday from the decision!
> If it is Android then Microsoft will still want its license fee, for all those "patent infringements".
The only significant 'patent' is for FAT32 long file names. This is only used when SD cards are required to be compatible with other devices. No SD card, no 'patent', no payment to MS. (which is why Nexus devices don't have SD slots).
> In fact it will probably cost more than the free Windows 10.
The 'free' Windows 10 does not apply to businesses. They will still pay for Software Assurance and could get Windows 10 through that. It is also only 'free' for the _supported_ life of the _device_ (after the first year). If the device is out of warranty than it is no longer a supported device and is no longer 'free'. It also does not apply to XP, let alone any Embedded versions.
"upgrade from xp embedded to 8.1 embedded a known upgrade path"
Known, yes. Easy, no. For a start, it means a complete hardware refresh because the hardware capable of running XP will barely run 8.1, if at all. And there is no upgrade install, 8.1 has to be installed from scratch. The latter will probably be done anyway as it is much easier to image a 8.1 install.
There's another significant difference: for Android you can use something slightly more powerful than a Raspberry PI (you're driving a keyboard, card reader, a screen, a network card and a cash dispenser for essentially a dumb terminal functionality, how much CPU and RAM do you need for that?) vs. a full fledged Wintel box for 8.1
"re-certifying a totally new OS and rewriting all the software from scratch?"
Not sure of the details, but I think that certification has to be done anyway unless the exact same software and hardware is used, which is not going to happen (see above)
As for rewriting the software from scratch, it has to be done if/when the old software was written using a technology no longer supported. Which given the list of abandoned Microsoft technologies of the last decade, that is very likely the case. So a rewrite is already in the cards.
"all to save possibly £20-£40 per machine for a windows licence?"
I think that when you add up the hardware savings, the license savings, the support savings, plus the hardware independence and the freedom to go on your own schedule for updates that's a bit more than a couple of tenners. More like a couple of thousands. Multiply that by the number of ATMs to be upgraded and here's your nice holiday.
NCR is making a clever move.
"That's in order to run and install the evaluation system - hence needing a DVD ROM drive or USB thumbdrive. It is NOT a requirement list for Win8.1 embedded itself, which will happily run on XP's minimum requirements."
I strongly doubt that, especially if we're talking about XP embedded's minimum requirements. Although the requirements listed for RAM and drive space for embedded 8.1 here are not that far in excess of a fully updated regular XP's requirements for practical use. I wouldn't be surprised if XP embedded is still happy with 256 MB of RAM and 4GB of drive space though.
Intresting news day. First Nokia-Alcatel Lucent (now closed for new posts after two posts?) and then this article.
My response to NCR is "why did it take you so long" and I think the banks have started to ask themselves how they have accepted Windows for so long. I think they have started to demand a better choice from NCR.
I would perhaps not write about this but I had a few programmer’s fingers in the POS/ATM pot then long ago.
There was the surprise in how easily IBM gave up and there was a time when Nixdorf delivered ATM in most European countries. The part left of Nixdorf is now Wincor Nixdorf. Quit strong on POS and using WIN/XP, WIN/XP embedded and Linux far as I know.
Then there was Windows all over the place and no matter what we think of Bill Gates he was a superb sells man.
The problem banks have been facing for such a long time is not some royalty payment to Microsoft but the lack of security the never ending problems with a fraud enabling OS where ever increasing amounts of money have been stolen, just too much work, add to that the fact that there is no help in sight.
Linux, there is no other choice.
The banks or NCR's logic is confused. BSD will be stronger - thinking OpenBSD.
OTOH Google is paying big bucks and rewards for security holes to be patched and is rapidly overtaking Microsoft in the security/trust area. So looking ahead 10 years, Google will win, and have all those facebook capabilites and facial recognition for nix!
Google and Android is the right choice, and MS is going to have fewer cash cows. The other option is to run the Microsoft ATM software in the cloud, and hope some hacker does not embellish the protocol to eject all notes. Right choice.