The Irish STV implementation also has to redistribute so called "surplus" votes.
Since it features multiple candidate constituencies the amount of votes required to get elected is not a simple majority but a quota defined by the Droop formula (Total number of valid ballots/(Total number of candidates +1))+1. Ballots for candidates who exceed the quota have a surplus and that surplus gets redistributed according to the next preference on the ballot. The exact mechanism for choosing the actual votes that comprise the surplus amount is random and those randomly selected votes are then transferred as full votes to the next preference candidate. So when a candidate has 10000 votes with a quota of 8500, 1500 ballots are chosen at random and the preferences in those ballots are used to transfer them to the remaining candidates in play.
For situations where a candidate gets a surplus on a second count (ie including transferred preferences from an eliminated candidate or from surplus votes from an earlier elected candidate) only the ballots transferred at the last stage are used when selecting the surplus votes to be transferred.
These shortcuts were introduced to speed up manual paper counts but they meant that the task of comparing an electronic count to a paper Voter Verified Audit Trail (VVAT) presents an interesting problem. In order to be able to fully and accurately validate the electronic count the VVAT records would have to be able to be tied exactly to the sequence of the electronic votes (so that each electronic record could be tied to each paper record and the random selections for surplus redistributions could be matched up). One solution to this would be to remove the shortcuts for electronic voting but that would have meant moving to e-Voting entirely as they could not use two different counting methods in different constituencies. So they had to implement an e-Voting STV counting mechanism that followed the same rules as a paper count would. Not hard to do but this then led to a further issue for those of us arguing for a voter verified audit trail for any e-voting system.
One of the Irish Government's least silly arguments against any VVAT for e-Voting was that such a capability might be compromised and could result in someone figuring out exactly how (some) individual voters had voted. Since the Irish constitution explicitly specifies that parliamentary voting must be secret this was something they were very much afraid of - it's notable that since the constitution does not explicitly require counting votes to be accurate (it only implies this) they were less concerned about that. Anyway that's how it seemed to me when I met them about the issue - they didn't say it as bluntly as that but they were terrified about the potential secrecy problems but only worried about the potential for "small" errors.
The real problems with the Irish e-Voting debacle had very little to do with the complexities of an STV count - they were the same as they were\are in most other counties though. The machines in question were provided by private companies, closed and not adequately tested by properly independent security professionals, the vote tabulation software was also closed, similarly unavailable for inspection by independent specialists and most worryingly it was never available any significant period of time ahead of any given election as it had to be rewritten for each count. The lack of a voter verified paper audit capability (which could have been implemented safely despite the concerns described above) meant that the systems could be attacked\compromised\fail in ways that could materially affect an election without being detected. In the end though few of those problems led to the current Government's decision to abandon the problem, they finally got fed up with the political and financial costs associated with fighting to keep the project alive and they gave up. I'm pretty sure that many of the Government Ministers and civil servants involved still think that the Nedap\Powervote e-Voting system was perfectly fine.
Whoa. I think I can help here...I speak a little PHB:
Thanks AC. Glad to see you went to the comedy school of IT.
"I manage the people who run the email servers for my company. I have a degree in business; I am skilled at synergizing my big-picture ideas on a going-forward basis."
No business degree, sorry. Just an engineer and I manage nobody, I design and build the systems. i'm glad that you think I'm qualified to run the whole show, I'll make sure to remember that at my next review.
"We need secure logins, but we don't trust our users."
Well no I don't trust my users, and neither does any other systems admin but that's not the point. Building a secure and usable access control mechanism for mobile devices is hard. Would you be happy if you hired a systems admin who accepted that a username and password alone was sufficient for remote access into your systems? If so then its time you reviewed your risk posture - for my part I like to use RSA-Keys, Certs and one time tokens for that sort of thing. Passwords do not cut it, sorry.
"We did not cover secure IMAP in my MIS classes."
Actually true but only because I never attended any MIS classes. Anyway I was talking about authentication protocols and not mail protocols here so I don't see your point. Mutually authenticated secure IMAP would be good if it turns out to be possible to figure out a secure way to distribute certificates to the device but there is no indication that the iPhone will ship with a good enough certificate enroller and as a closed system writing our own is not an option.
"Encrypted, password-based authentication is too simple to possibly guarantee my job."
100% true. I'd be fired if I suggested it and I'd expect no less. Seriously, passwords don't cut it for authentication over untrusted links in this day and age, if you haven't realized that yet then I suggest you start thinking about why good SSH implementations don't use them.
My day job involves creating processes that allow our enterprise to securely build, deploy and manage configurations to mobile devices like mobile phones and blackberry. What I need to do (as any other systems admin does) is to create a repeatable, secure and reliable method of taking control of a physical device, securing it (so data and credentials on that device are safe and my enterprise can authenticate both the device and the user later) and configuring it. When you want to do that for 20000 or more users on five continents over 80 or more cellular providers you really want to be able to fully automate the process. That requires an SDK and a reasonably complete manageability API at the OS level that is available to you.
Otherwise the option is to go manual. Apart from the near impossibility of getting a user to reliably communicate a device's identity (ie a hardware device ID\Serial number\IMEI number) back into a configuration database you cannot seriously ask normal end users to poke around in config dialogs, changing and tweaking settings and expect everything to work. It can be done but your support desk overhead becomes criminally expensive. I haven't even begun to discuss the difficulties involved in effectively securing the authentication protocols used for your end users services - what are we proposing? Cached user names and passwords? X.509 certificates and mutual authentication? OTP's? If so how do you configure both ends so that you preclude man in the middle attacks and credential stealing?
Why do we need to authenticate the device? Well what happens when a user loses a device or its stolen? That happens on average twice a day for us worldwide BTW. We revoke the device's access and then provision the user with a new one. To do that we need to be able to auth the devices too. We could get away with not doing that but would end up having to cancel user accounts to remain secure.
The closed nature of the iPhone precludes the above and that is the reason enterprises are saying that it is not suitable. I think it's going to be a great consumer device and, yes, I want one too but we aren't going to see support and adoption in large organisations that care about security until they provide the tools to manage the platform correctly (or just open it up). If Apple come out with comprehensive configuration subsystem using (for example) OMA-DM via SyncML then things would be looking up.
Exchange support would be nice but it's not critical at all even for monocultural Microsoft shops. Anyone can write a gateway interface between Exchange and anything else if they want to. It may be proprietary but it isn't closed. That's a very important point here.
A well designed hardware cryptographic solution presents an extremely hard barrier if implemented well. The original X-Box failed because short cuts were taken in the architecture and keys were transmitted across a high speed bus but the same does not apply to the X-Box 360. It has thus far resisted all of the attempts to circumvent it, the minor hacks achieved to date have done little to break down the core security of that system despite significant efforts on the part of the X-Box hacking\mod community.
Forget about separate TPM's in chipsets - the "ideal" solutions are now being rolled out pre-built into consumer CPUs. Apart from the clever crypto parts of the X-Box 360's CPU, both Intel's LaGrande and AMD's Presidio provide robust "Trusted Computing" features that (could) fully prevent the type of attacks that have been used in the WinDVD key discovery attacks. All three systems implement in-cpu protected key storage and secure memory for key dependent operations. Even without the absolute control that the XBox 360 enforces through its trusted boot process the LaGrande\Presidio technologies allow developers to build DRM solutions that are effectively invulnerable to key discovery attacks on any OS.
Exactly like that. The OMA-DM posse wants absolute control of the hardware and all of the data that moves in and out of the devices. This is not just about DRM for "copyright protection", it's about monetizing everything subscribers might want to do with their phones. Folks I've talked to in the industry are quite open about the fact that the cellular providers want these levels of hardware based TC and DRM so that they can prevent their users doing anything at all that is not sanctioned by them, ie not paid for as an extra by the users. Want to save your photos to the web? Pay us. Want to change your ring tone? Pay us. Want to synchronise your calendar? Pay us.
And before people say it will never work, they already sell close to half a billon devices a year that operate under that model and they want this so they can be certain that it can continue.
You're missing the point here - this is supposedly a Trusted Computing architecture. The locks on this are not something as trivial as a serial number that is hard to track down. The core has a cryptographic component that provides for hardware based key management and secure crypto functions. That module will never export its unique private key(s) because the hardware design doesn't provide any instructions that allow that to happen. Good luck attacking it that way, it might be possible if they stuffed up the design but I doubt it.
Furthermore if it follows the MS TC model then the CPU's crypto store will also have MS X-Box boot and app signing Root certs. All code, especially the boot process will have to be signed by something that will pass a check against those Root Certs. At a guess I'd say they have more than one of each type and they can be revoked via firmware (ie over XBox live, or via code distributed in games) just in case their primary leaks. Finding buffer overflows or figuring out how to code the instructions for an alternative boot firmware wont help unless you can figure out how to sign the code you feed into CPU. If the hardware design is properly secure then that will require breaking a strong crypto system equivalent to that used in X.509 certs in order to compromise those MS owned signing keys.
This is a much much harder problem than compromising the original X-Box (which only used software based crypto so it could be subverted by replacing the boot code) or the PSP (which seems to rely on no secure execution model at all). MS certainly know how this should be done, the question is did they actually try to do it and if so did they succeed. That is the main reason I'm interested in this X-Box 360 hacking attempt, it's success will show how serious MS actually are about extreme DRM.
My guess on that is that the answer is very interested indeed, if they can successfully implement a popular consumer device with a hard TC architecture then there are a lot of people out there who will want them to share it with them - the Cellular Telco's in particular love this stuff and will happily get into bed with MS if they can sell them a proven TC architecture that is resistant to attack.
This message needs to be repeated, and repeated often.
The first rule of DRM is, by contrast, "We give the client the encrypted content, the keys, and the decoder, and hope that he won't work out how to use them."
As you say, DRM is inherently snake-oil. It's an attempt to fool the uninformed that there is a way for content owners to give them something without actually giving them full access to it. Without hardware specifically restricting what creative people can and will do very few implementations will give any half way competent attacker any serious issues.
The only way it can be strongly secure is if the hardware protects private keys in a totally controlled manner and at the same time does not allow end user access to the secure store for those keys in any way. That is what NGSCB\Palladium is supposed to do "ideally" but it has to be flawed in an edge only implementation (where there is no centralised control of some keys). Specifically the problem is what happens when the consumer needs to move their content around - either the NGSCB device(s) allow for key export and import (and thereby expose the media access keys to discovery) or a decision is made to deny the user the ability to ever move DRM'ed data between devices. Now the content owners probably could care less about that but the hardware vendors who will want users to regularly upgrade their devices must care (they want users to upgrade regularly) and they are the folks who have to implement NGSCB. Bit of a catch 22 there. It's something that consumers might fall for once but they'll avoid any product that burns them in that way like the plague in the long term - a classic short term business strategy with no future.
The alternative approach is to recognise that the edge only solution is unworkable and that you have to centralise some user identity and key management in conjunction with NGCSB and thus allow devices to be enabled selectively. That is the general approach taken by MS's DRM which relies on a registration process built on their.NET Passport thing with all content encrypted to the user's primary key before it is sent to the user. Apart from the distribution problems this causes (and which perfectly explains iTunes behavior as you explain) the problem there is that MS's cavalier attitude to.Net Passport accounts demonstrates the fundamental problem with this: Users cede their rights to the content to the provider in perpetuity. The astounding thing is that while the best reason for doing DRM this way is to ensure end users can be kept somewhat happy (by giving them some way to continue to have access to material they have purchased in the past) MS have completely botched it by linking it to an "identity management" system where they arbitrarily delete inactive accounts. Users are not generally aware of this or why it's a problem but they are learning slowly as they discover how hard it is to move their content onto new systems when they upgrade. In MS's case their policy of aggressively disabling "inactive".Net passport accounts effectively denies end users ongoing legitimate access to content they own when they (MS) arbitrarily disable "idle" accounts. If anyone has any doubts about this then purchase some MS DRM'ed content using a newly created.Net account, leave the account inactive for 2 months without touching it then try to gain access to your content on a device that hasn't been registered. The software only implementations of MS-DRM have been cracked a number of times so this isn't too much of a headache for any disgruntled user right now but with a "good" NGSCB platform the MS DRM approach would allow them to regularly steal content from users who's only mistake was to move content to a newer media device. Once again comsumers may agree to get burned by that once through ignorance but once it happens to them they will never use it again - once again a short term self defeating business strategy. Or at least so it
Not true at all - the Embedded Visual C++ V4 IDE is completely free to use, both it and the Windows Mobile\Smartphone SDK are downloadable from MS. You can quibble about the license but it is very much free "as in beer" at least, if not completely free "as in speech"
The base CE 4.x & 5.0 platform dev environments themselves are available if you choose to subscribe and they give you far more visibility to the underlying implimentation of the various API's if you need more than is explicitly exposed by MSDN.
Everything that's needed for this particular project (porting Minimo to CE) is publicly available.
Remain convinced about the imminent death or otherwise of Windows CE if you like but it's completely false to say that there is a lack of free and open access to development tools and API's.
Say again.
Greg Dyke was forced to resign as DG following the Hutton report, Tony Blair wanted him gone and he went. It might not be explicit but the UK government effectively has ultimate control.
They have - quite ironic that "The Internet Storm Centre" doesn't scale to handle the curious Slashdot horde.
This begs the question of what is the Slashdot Threshold? And whether there would be any money to be made for the site in having a "Load Tested by Slashdot" logo.
for readability AND unamibiguity, I use
MM-DDD-YYYY (e.g. 07-Mar-2004). I've been using this format since the day I started working for a company that did 99% of its business with non-US customers (nearly a decade ago). Some US folks may look at me funny when I do it that way, but nobody has EVER been confused about what date I meant....
Well you just confused me, MM-DDD-YYYY is not what you used - it's DD-MMM-YYY.
This is older news covered here on Slashdot a few days ago. The Register has also posted an updated analysis and are now of the opinion that the memo in question doesn't reveal anything new about the SCO\Microsoft financial entanglement.
Java -I don't use Java for much but just did a run through with Maestro and it seems to manage under pressure, chews up a few 100Meg virtual memory as always but I'm still able to work with the 3D stuff at 20-100fps. That's with IBM Java 1.2 (build wndev20030516.
Java in Firefox. Just to get something more typical I installed Sun's runtime (J2RE 1.4.2_03). No issues with a bunch of web embedded stuff I checked.
Python. Installs and runs some of it's own samples with no issues.
Perl. You didn't ask but I use Perl a lot. No issues with V5.8.3.
All of the above are for XP SP2 V2055 on an IBM T41p (Pentium M) not an AMD64 system where NX flagging is\can be enabled. Microsoft's page on NX (mostly an app issue for SP2) and PAE (mostly a driver issue for SP2) is very informative.
Now that I look at this in detail it seems that XP SP2's NX support requires PAE support to be enabled. PAE is an Intel x86 hack to allow access to a 36bit memory space. M$ only support it on W2K Advanced Server, XP and W2K3 so unless that policy is changed in a future SP then you're probably right.
PAE is not native 64bit mode though - and 64bit'ness isn't required for it. Lack of NX in consumer Intel processors clearly has nothing to do with 64bit support as such. Since NX support is fairly simple and provides such an easy marketing benefit (Roll UP! Virus Proof Processors (TM) yadda yadda..) it does all seem to indicate that Intel know that enabling NX support will break lots of legacy hardware (and maybe software if the MS comment about Delphi is accurate). Their decision to wait until Tejas (late Q1 2005) before having it in consumer oriented procesors gives the hardware market time to build and debug reliable PAE supporting drivers and apps thanks to AMD.
The NX support is only one of the major changes and it will only affect AMD64 and Itanic for now. The lack of NX in Prescott's "IA32e" extensions is listed here by an intel source and discussed in detail in this thread on Ace's Hardware. This unofficial comment in that thread might lead a true conspiracy theorist to conclude that there might be widespread issues with turning on NX support right now. Reading MS's Developer overview for SP2 here also gives the impression that NX related problems will not be easy to workaround, at least for non open source apps\drivers. The fact that AMD haven't been making any effort to try to market the NX capabilities in AMD64 outside of the enthusiast market could be explained if there are major issues with SP2.
The RPC and DCOM changes are much more likely to have wider impacts - especially for enterprise applications.
The ICF changes are fairly light (unfortunately in my view) and not that hard for end users\admins to modify so even if there are issues workarounds will be fairly simple.
Rest easy bud (or maybe not) - QT, RealPlayer and Firefox certainly won't break, I use 'em and have a beta of SP2. No issues, at least on my setup, with these or any other of my apps. All Windows Service Packs break "some" applications, and the same applies to other OS's, the difference here is that MS are providing tools to help developers identify and rectify them in advance - that's certainly a good idea.
The real problem is that the benefits it (should) bring will not get deployed to the bulk of systems that need it - at 210Mb I can't see the majority of systems out there that really need it getting the whole thing downloaded, at least not within any reasonable time frame. Hopefully by the time it is actually released they will have a lite version on Windows update that can push the security improvements in a much smaller package.
Their decision to at least try to implement some long overdue fundamental improvements to the security of the architecture is to be welcomed no matter how over due it is. However despite that their decision not to add any outgoing filtering capability to the ICF doesn't make any sense to me and seems, well, just stupid really.
That's probably why NASA already have the Mars Telecommunications Orbiter scheduled for launch in 2009. This is still being spec'ed out but optical links, which are currently described as testing\Proof of concept and primary Ka-Band capabilities (once proven in MRO below) are both in plan right now.
Next year's Mars Reconnaissance Orbiter has significantly better telecoms relaying capability than the existing Odyssey\MGS orbiters - 6Mbits/sec using Ka-band. This goes with some major upgrades to the DSN as this currently has 10Mbit/sec limitations for telecoms at Mars distances AFAIK. This JPL presentation has lots of detail on the near term\medium term plans and proposals and where the IPN fits in. This indicates that the bandwidth of optical links to mars would be in the 30-300Mbps range.
OK then speaking as an admin in a large outfit that is predominantly MS this guys approach is typical of MS management. They (the MS suits) do their damnedest to imply that it's someone elses fault and even though they must understand this stuff they pile on the FUD in order to avoid taking the rap when they should.
Take the SQL patch that remedied the vulnerability used by Slammer\Sapphire. While this was available for >6 months before being widely exploited it was so poor on release by MS that it had never been widely deployed. In fact most people who needed to apply it would never be able to tell they needed it (it was labelled a patch for SQL Server only but was needed by Age of Empires among hundreds of other home user apps). So they made it available for a fraction of the systems that were vulnerable (Pure SQL only, not clustered, not MSDE, not Visual Studio) and you needed a lot of Windows and SQL architecture expertise to be certain you had actually installed it correctly and comprehensively on even the small fraction of systems you actually had a patch for.
So they released their non-patch and promptly forgot about it until Slammer appeared (despite a growing body of evidence prior to Slammer that it was not an adequate fix). Once Slammer was released they reworked the patch and their information on it repeatedly - to the point that they eventually had at least a dozen variations and pages of instructions\guidelines on using it.
I had the wonderful experience of being in a teleconference with MS engineering support during the peak of the Slammer outbreak (well +-12 hours after the peak) and I am certain that they had a bunch of MS legal heads in the room constantly putting them on mute and telling them not to answer our questions. They did not give us anything like a realistic picture of the scope of the problem at that time, would not confirm or deny that the patches were being reworked. And I know the engineers in question had a fair idea of all of the correct answers.
sorry bud - those of us who were actually building systems waaay back when the Pentium was launched
remember that the benchmarks of the day proved that the AMD chips available at the time (mid\late '94 I think) were definitely not "blown away" by the P5, quite the opposite in fact as shown
here and they continued to be able to beat the P5's early iterations through it's first few generations as shown in these vinatage 96 benchmarks . That pattern has repeated more or less ever since with Intel generally losing the edge noticably (but temporarily) every time they had a major architecture shift (386->486, 486-P5, P5-P6, maybe not so on PII -> PIII (I wasn't paying attention), definitely at PIII-P4, and currently with A64\Opteron vs Prescott - at least for now. At a guess the Prescott (or Tejas) will scale past A64's sometime later this year in real world benchmarks, AMD will respond (A64-EE!) and around we'll go again. Who's "better" only depends on when you're looking, certainly neither has ever "blown" the other away, thankfully as the competition has benefited all of us. Mind you the fact that AMD have actually taken the architectural lead so commandingly this time round is a real shake up, this is the first time that I recall that Intel are following (sort of at least) not leading.
The Intel Inside campaign was used to create a marketing brand that has clearly worked very well, you seem to think the P5-Pentium clearly outclassed the opposition when it was introduced - it did not.
As you say this is already supported by an appropriately compiled Linux kernel or XP-64 on the A64 & Opteron. The wider benefit for all of us is that this is to be included in XP SP-2 which will hopefully become endemic sometime this year. See this eWeek article . At that point this becomes an excellent marketing tactic for AMD. I haven't examined the IA32e documents for myself yet but those who have seem to think Intel have left out support of the NX flag - see sandpile.org. If this is true then Intel are handing AMD a real advantage as far as consumer marketing is concerned. Even I could spin that so that that it looked like more of an advantage than 64bit capability which to be honest is a real hard sell as far as your average consumer is concerned.
Well - for us (in Ireland) the main benefit is that it speeds the counting process up. This is a debatable benefit but it is one here at least
About four months ago I was asked by the Irish Department of Environment, Heritage and Local Government to provide a technical assessment of their implimentation plans for our nation wide Local and European Parliamentary elections in June (more in this previous Slashdot Article. In the spirit of openness I should own up to being an IT security specialist for a large US multinational (not MS). It's also worth pointing out for those that don't know that the Irish voting system is both complex (Single transferable Vote - Proportional representation) and extremely well understood by the population - we have it drilled into us virtually from the cradle and we love it.
The Good News (for us Paddy's). The system and plans they presented are generally very good for the type of system that it is. It's not open source but it has had some level of competant independant review. It's non networked, and the tallying systems are also non networked. It has already been trialled in some constintuencies in the last general election here with very favourable voter reactions. It reduces the counting time for a typical constituency from ~24 hours to ~ 2 hours. The bulk of that ~2 hours is the time taken to physically transfer the results from the tally machines (stored in redundant flash modules) back to the central count. Re-counts take minutes rather than days (we had 2 constintuency recounts take more than a week last time round). From a security best practice point of view they showed a sensible approach to securing the devices, the tallying machines and the physical\personel processes involved. An almost identical system (same voting booths but different vote tally code due to our specific electoral rules have been in use in Germany and The Netherlands for a number of years without any evidence of issues that I am aware of (but maybe someone here is). They take voting privacy very seriously - Irish constitutional case law has made it clear that a voting system cannot even theoretically allow an individuals vote to be known, that specific feature has had to be audited independantly
The Bad News (sort of). This system is electronic only - there is no provision for an independantly auditable "paper vote". This has been and is still under consideration but the response I got was that it would compromise the vote privacy ruling. The problem for us is that our voting system has inherent short cuts (ie hacks) in the transfer system that uses sampling to allocate so called surplus votes. This sounds a bit bizarre but it works, we understand it and above all everyone accepts it. The technical details of the problem are outlined well in this thread on www.verifiedvoting.org . Unless the paper votes and the electronic votes are randomised identically then paper vote counts will not tally precisely with the electronic tally. If the resulting vote is very close then the difference could be enough to change the election result. If both are randomised identically then by implication a voters actual vote could technically be identified - which is illegal. Of course the problem would go away if the electoral rules allowed for complete electronic counting (no need for the time saving hacks anymore) but until e-voting is proven that will not happen. It's an interesting dilemma and I was impressed that the government officials understood the problem as well as they did.
I had many other concerns which I voiced but I was far from un-impressed by these guys, particularly since most of them weren't tech heads. They were keen to talk and listen, had researched things very well and took on board much of what I suggested.
In the end they are going with the system more or less as it is but with lots of physical and process security rather than th
Slashdot Mirror
The Irish STV implementation also has to redistribute so called "surplus" votes.
Since it features multiple candidate constituencies the amount of votes required to get elected is not a simple majority but a quota defined by the Droop formula (Total number of valid ballots/(Total number of candidates +1))+1. Ballots for candidates who exceed the quota have a surplus and that surplus gets redistributed according to the next preference on the ballot. The exact mechanism for choosing the actual votes that comprise the surplus amount is random and those randomly selected votes are then transferred as full votes to the next preference candidate. So when a candidate has 10000 votes with a quota of 8500, 1500 ballots are chosen at random and the preferences in those ballots are used to transfer them to the remaining candidates in play. For situations where a candidate gets a surplus on a second count (ie including transferred preferences from an eliminated candidate or from surplus votes from an earlier elected candidate) only the ballots transferred at the last stage are used when selecting the surplus votes to be transferred.
These shortcuts were introduced to speed up manual paper counts but they meant that the task of comparing an electronic count to a paper Voter Verified Audit Trail (VVAT) presents an interesting problem. In order to be able to fully and accurately validate the electronic count the VVAT records would have to be able to be tied exactly to the sequence of the electronic votes (so that each electronic record could be tied to each paper record and the random selections for surplus redistributions could be matched up). One solution to this would be to remove the shortcuts for electronic voting but that would have meant moving to e-Voting entirely as they could not use two different counting methods in different constituencies. So they had to implement an e-Voting STV counting mechanism that followed the same rules as a paper count would. Not hard to do but this then led to a further issue for those of us arguing for a voter verified audit trail for any e-voting system.
One of the Irish Government's least silly arguments against any VVAT for e-Voting was that such a capability might be compromised and could result in someone figuring out exactly how (some) individual voters had voted. Since the Irish constitution explicitly specifies that parliamentary voting must be secret this was something they were very much afraid of - it's notable that since the constitution does not explicitly require counting votes to be accurate (it only implies this) they were less concerned about that. Anyway that's how it seemed to me when I met them about the issue - they didn't say it as bluntly as that but they were terrified about the potential secrecy problems but only worried about the potential for "small" errors.
The real problems with the Irish e-Voting debacle had very little to do with the complexities of an STV count - they were the same as they were\are in most other counties though. The machines in question were provided by private companies, closed and not adequately tested by properly independent security professionals, the vote tabulation software was also closed, similarly unavailable for inspection by independent specialists and most worryingly it was never available any significant period of time ahead of any given election as it had to be rewritten for each count. The lack of a voter verified paper audit capability (which could have been implemented safely despite the concerns described above) meant that the systems could be attacked\compromised\fail in ways that could materially affect an election without being detected. In the end though few of those problems led to the current Government's decision to abandon the problem, they finally got fed up with the political and financial costs associated with fighting to keep the project alive and they gave up. I'm pretty sure that many of the Government Ministers and civil servants involved still think that the Nedap\Powervote e-Voting system was perfectly fine.
Thanks AC. Glad to see you went to the comedy school of IT.
"I manage the people who run the email servers for my company. I have a degree in business; I am skilled at synergizing my big-picture ideas on a going-forward basis."
No business degree, sorry. Just an engineer and I manage nobody, I design and build the systems. i'm glad that you think I'm qualified to run the whole show, I'll make sure to remember that at my next review.
"We need secure logins, but we don't trust our users."
Well no I don't trust my users, and neither does any other systems admin but that's not the point. Building a secure and usable access control mechanism for mobile devices is hard. Would you be happy if you hired a systems admin who accepted that a username and password alone was sufficient for remote access into your systems? If so then its time you reviewed your risk posture - for my part I like to use RSA-Keys, Certs and one time tokens for that sort of thing. Passwords do not cut it, sorry.
"We did not cover secure IMAP in my MIS classes."
Actually true but only because I never attended any MIS classes. Anyway I was talking about authentication protocols and not mail protocols here so I don't see your point. Mutually authenticated secure IMAP would be good if it turns out to be possible to figure out a secure way to distribute certificates to the device but there is no indication that the iPhone will ship with a good enough certificate enroller and as a closed system writing our own is not an option.
"Encrypted, password-based authentication is too simple to possibly guarantee my job."
100% true. I'd be fired if I suggested it and I'd expect no less. Seriously, passwords don't cut it for authentication over untrusted links in this day and age, if you haven't realized that yet then I suggest you start thinking about why good SSH implementations don't use them.
Otherwise the option is to go manual. Apart from the near impossibility of getting a user to reliably communicate a device's identity (ie a hardware device ID\Serial number\IMEI number) back into a configuration database you cannot seriously ask normal end users to poke around in config dialogs, changing and tweaking settings and expect everything to work. It can be done but your support desk overhead becomes criminally expensive. I haven't even begun to discuss the difficulties involved in effectively securing the authentication protocols used for your end users services - what are we proposing? Cached user names and passwords? X.509 certificates and mutual authentication? OTP's? If so how do you configure both ends so that you preclude man in the middle attacks and credential stealing?
Why do we need to authenticate the device? Well what happens when a user loses a device or its stolen? That happens on average twice a day for us worldwide BTW. We revoke the device's access and then provision the user with a new one. To do that we need to be able to auth the devices too. We could get away with not doing that but would end up having to cancel user accounts to remain secure.
The closed nature of the iPhone precludes the above and that is the reason enterprises are saying that it is not suitable. I think it's going to be a great consumer device and, yes, I want one too but we aren't going to see support and adoption in large organisations that care about security until they provide the tools to manage the platform correctly (or just open it up). If Apple come out with comprehensive configuration subsystem using (for example) OMA-DM via SyncML then things would be looking up.
Exchange support would be nice but it's not critical at all even for monocultural Microsoft shops. Anyone can write a gateway interface between Exchange and anything else if they want to. It may be proprietary but it isn't closed. That's a very important point here.
A well designed hardware cryptographic solution presents an extremely hard barrier if implemented well. The original X-Box failed because short cuts were taken in the architecture and keys were transmitted across a high speed bus but the same does not apply to the X-Box 360. It has thus far resisted all of the attempts to circumvent it, the minor hacks achieved to date have done little to break down the core security of that system despite significant efforts on the part of the X-Box hacking\mod community. Forget about separate TPM's in chipsets - the "ideal" solutions are now being rolled out pre-built into consumer CPUs. Apart from the clever crypto parts of the X-Box 360's CPU, both Intel's LaGrande and AMD's Presidio provide robust "Trusted Computing" features that (could) fully prevent the type of attacks that have been used in the WinDVD key discovery attacks. All three systems implement in-cpu protected key storage and secure memory for key dependent operations. Even without the absolute control that the XBox 360 enforces through its trusted boot process the LaGrande\Presidio technologies allow developers to build DRM solutions that are effectively invulnerable to key discovery attacks on any OS.
And the rather large piece of debris spotted by the crew - possible piece of insulating blanket from the orbiter itself 5-6 feet long.
Parent needs to be modded up more it is the most coherent comment on the topic posted so far. One minor nit pick - a 65nm\45nm fab costs about $3.5billion see here for the investment required for Intel's Fab 28 in Israel. That's an increase of $1.5 billion on the cost of the existing 90nm\65nm Intel Fab 24 in Ireland .
Exactly like that. The OMA-DM posse wants absolute control of the hardware and all of the data that moves in and out of the devices. This is not just about DRM for "copyright protection", it's about monetizing everything subscribers might want to do with their phones. Folks I've talked to in the industry are quite open about the fact that the cellular providers want these levels of hardware based TC and DRM so that they can prevent their users doing anything at all that is not sanctioned by them, ie not paid for as an extra by the users. Want to save your photos to the web? Pay us. Want to change your ring tone? Pay us. Want to synchronise your calendar? Pay us.
And before people say it will never work, they already sell close to half a billon devices a year that operate under that model and they want this so they can be certain that it can continue.
You're missing the point here - this is supposedly a Trusted Computing architecture. The locks on this are not something as trivial as a serial number that is hard to track down. The core has a cryptographic component that provides for hardware based key management and secure crypto functions. That module will never export its unique private key(s) because the hardware design doesn't provide any instructions that allow that to happen. Good luck attacking it that way, it might be possible if they stuffed up the design but I doubt it.
Furthermore if it follows the MS TC model then the CPU's crypto store will also have MS X-Box boot and app signing Root certs. All code, especially the boot process will have to be signed by something that will pass a check against those Root Certs. At a guess I'd say they have more than one of each type and they can be revoked via firmware (ie over XBox live, or via code distributed in games) just in case their primary leaks. Finding buffer overflows or figuring out how to code the instructions for an alternative boot firmware wont help unless you can figure out how to sign the code you feed into CPU. If the hardware design is properly secure then that will require breaking a strong crypto system equivalent to that used in X.509 certs in order to compromise those MS owned signing keys. This is a much much harder problem than compromising the original X-Box (which only used software based crypto so it could be subverted by replacing the boot code) or the PSP (which seems to rely on no secure execution model at all). MS certainly know how this should be done, the question is did they actually try to do it and if so did they succeed. That is the main reason I'm interested in this X-Box 360 hacking attempt, it's success will show how serious MS actually are about extreme DRM.
My guess on that is that the answer is very interested indeed, if they can successfully implement a popular consumer device with a hard TC architecture then there are a lot of people out there who will want them to share it with them - the Cellular Telco's in particular love this stuff and will happily get into bed with MS if they can sell them a proven TC architecture that is resistant to attack.
As you say, DRM is inherently snake-oil. It's an attempt to fool the uninformed that there is a way for content owners to give them something without actually giving them full access to it. Without hardware specifically restricting what creative people can and will do very few implementations will give any half way competent attacker any serious issues.
The only way it can be strongly secure is if the hardware protects private keys in a totally controlled manner and at the same time does not allow end user access to the secure store for those keys in any way. That is what NGSCB\Palladium is supposed to do "ideally" but it has to be flawed in an edge only implementation (where there is no centralised control of some keys). Specifically the problem is what happens when the consumer needs to move their content around - either the NGSCB device(s) allow for key export and import (and thereby expose the media access keys to discovery) or a decision is made to deny the user the ability to ever move DRM'ed data between devices. Now the content owners probably could care less about that but the hardware vendors who will want users to regularly upgrade their devices must care (they want users to upgrade regularly) and they are the folks who have to implement NGSCB. Bit of a catch 22 there. It's something that consumers might fall for once but they'll avoid any product that burns them in that way like the plague in the long term - a classic short term business strategy with no future.
The alternative approach is to recognise that the edge only solution is unworkable and that you have to centralise some user identity and key management in conjunction with NGCSB and thus allow devices to be enabled selectively. That is the general approach taken by MS's DRM which relies on a registration process built on their .NET Passport thing with all content encrypted to the user's primary key before it is sent to the user. Apart from the distribution problems this causes (and which perfectly explains iTunes behavior as you explain) the problem there is that MS's cavalier attitude to .Net Passport accounts demonstrates the fundamental problem with this: Users cede their rights to the content to the provider in perpetuity. The astounding thing is that while the best reason for doing DRM this way is to ensure end users can be kept somewhat happy (by giving them some way to continue to have access to material they have purchased in the past) MS have completely botched it by linking it to an "identity management" system where they arbitrarily delete inactive accounts. Users are not generally aware of this or why it's a problem but they are learning slowly as they discover how hard it is to move their content onto new systems when they upgrade. In MS's case their policy of aggressively disabling "inactive" .Net passport accounts effectively denies end users ongoing legitimate access to content they own when they (MS) arbitrarily disable "idle" accounts. If anyone has any doubts about this then purchase some MS DRM'ed content using a newly created .Net account, leave the account inactive for 2 months without touching it then try to gain access to your content on a device that hasn't been registered. The software only implementations of MS-DRM have been cracked a number of times so this isn't too much of a headache for any disgruntled user right now but with a "good" NGSCB platform the MS DRM approach would allow them to regularly steal content from users who's only mistake was to move content to a newer media device. Once again comsumers may agree to get burned by that once through ignorance but once it happens to them they will never use it again - once again a short term self defeating business strategy. Or at least so it
Not true at all - the Embedded Visual C++ V4 IDE is completely free to use, both it and the Windows Mobile\Smartphone SDK are downloadable from MS. You can quibble about the license but it is very much free "as in beer" at least, if not completely free "as in speech"
From the links in the Article:
eMbedded Visual C++ 4.0 [This is the full GUI IDE + API and language reference]
eMbedded Visual C++ 4.0 SP4 [Brings platform support up to WM2003 SE and Smartphone 2003]
SDK for Windows Mobile 2003-based Pocket PCs [Full API, documentation, dev environment and sample code]
The base CE 4.x & 5.0 platform dev environments themselves are available if you choose to subscribe and they give you far more visibility to the underlying implimentation of the various API's if you need more than is explicitly exposed by MSDN.
Everything that's needed for this particular project (porting Minimo to CE) is publicly available.
Remain convinced about the imminent death or otherwise of Windows CE if you like but it's completely false to say that there is a lack of free and open access to development tools and API's.
Say again.
Greg Dyke was forced to resign as DG following the Hutton report, Tony Blair wanted him gone and he went. It might not be explicit but the UK government effectively has ultimate control.
This begs the question of what is the Slashdot Threshold? And whether there would be any money to be made for the site in having a "Load Tested by Slashdot" logo.
This is older news covered here on Slashdot a few days ago. The Register has also posted an updated analysis and are now of the opinion that the memo in question doesn't reveal anything new about the SCO\Microsoft financial entanglement.
Java -I don't use Java for much but just did a run through with Maestro and it seems to manage under pressure, chews up a few 100Meg virtual memory as always but I'm still able to work with the 3D stuff at 20-100fps. That's with IBM Java 1.2 (build wndev20030516.
Java in Firefox. Just to get something more typical I installed Sun's runtime (J2RE 1.4.2_03). No issues with a bunch of web embedded stuff I checked.
Python. Installs and runs some of it's own samples with no issues.
Perl. You didn't ask but I use Perl a lot. No issues with V5.8.3.
All of the above are for XP SP2 V2055 on an IBM T41p (Pentium M) not an AMD64 system where NX flagging is\can be enabled. Microsoft's page on NX (mostly an app issue for SP2) and PAE (mostly a driver issue for SP2) is very informative.
PAE is not native 64bit mode though - and 64bit'ness isn't required for it. Lack of NX in consumer Intel processors clearly has nothing to do with 64bit support as such. Since NX support is fairly simple and provides such an easy marketing benefit (Roll UP! Virus Proof Processors (TM) yadda yadda ..) it does all seem to indicate that Intel know that enabling NX support will break lots of legacy hardware (and maybe software if the MS comment about Delphi is accurate). Their decision to wait until Tejas (late Q1 2005) before having it in consumer oriented procesors gives the hardware market time to build and debug reliable PAE supporting drivers and apps thanks to AMD.
The other good news is that the W3C's submission demonstrating that this should have been nullified due to prior art seem to have been listened to.
The RPC and DCOM changes are much more likely to have wider impacts - especially for enterprise applications.
The ICF changes are fairly light (unfortunately in my view) and not that hard for end users\admins to modify so even if there are issues workarounds will be fairly simple.
The real problem is that the benefits it (should) bring will not get deployed to the bulk of systems that need it - at 210Mb I can't see the majority of systems out there that really need it getting the whole thing downloaded, at least not within any reasonable time frame. Hopefully by the time it is actually released they will have a lite version on Windows update that can push the security improvements in a much smaller package.
Their decision to at least try to implement some long overdue fundamental improvements to the security of the architecture is to be welcomed no matter how over due it is. However despite that their decision not to add any outgoing filtering capability to the ICF doesn't make any sense to me and seems, well, just stupid really.
That's probably why NASA already have the Mars Telecommunications Orbiter scheduled for launch in 2009. This is still being spec'ed out but optical links, which are currently described as testing\Proof of concept and primary Ka-Band capabilities (once proven in MRO below) are both in plan right now.
Next year's Mars Reconnaissance Orbiter has significantly better telecoms relaying capability than the existing Odyssey\MGS orbiters - 6Mbits/sec using Ka-band. This goes with some major upgrades to the DSN as this currently has 10Mbit/sec limitations for telecoms at Mars distances AFAIK. This JPL presentation has lots of detail on the near term\medium term plans and proposals and where the IPN fits in. This indicates that the bandwidth of optical links to mars would be in the 30-300Mbps range.
Take the SQL patch that remedied the vulnerability used by Slammer\Sapphire. While this was available for >6 months before being widely exploited it was so poor on release by MS that it had never been widely deployed. In fact most people who needed to apply it would never be able to tell they needed it (it was labelled a patch for SQL Server only but was needed by Age of Empires among hundreds of other home user apps). So they made it available for a fraction of the systems that were vulnerable (Pure SQL only, not clustered, not MSDE, not Visual Studio) and you needed a lot of Windows and SQL architecture expertise to be certain you had actually installed it correctly and comprehensively on even the small fraction of systems you actually had a patch for.
So they released their non-patch and promptly forgot about it until Slammer appeared (despite a growing body of evidence prior to Slammer that it was not an adequate fix). Once Slammer was released they reworked the patch and their information on it repeatedly - to the point that they eventually had at least a dozen variations and pages of instructions\guidelines on using it.
I had the wonderful experience of being in a teleconference with MS engineering support during the peak of the Slammer outbreak (well +-12 hours after the peak) and I am certain that they had a bunch of MS legal heads in the room constantly putting them on mute and telling them not to answer our questions. They did not give us anything like a realistic picture of the scope of the problem at that time, would not confirm or deny that the patches were being reworked. And I know the engineers in question had a fair idea of all of the correct answers.
The Intel Inside campaign was used to create a marketing brand that has clearly worked very well, you seem to think the P5-Pentium clearly outclassed the opposition when it was introduced - it did not.
As you say this is already supported by an appropriately compiled Linux kernel or XP-64 on the A64 & Opteron. The wider benefit for all of us is that this is to be included in XP SP-2 which will hopefully become endemic sometime this year. See this eWeek article . At that point this becomes an excellent marketing tactic for AMD. I haven't examined the IA32e documents for myself yet but those who have seem to think Intel have left out support of the NX flag - see sandpile.org. If this is true then Intel are handing AMD a real advantage as far as consumer marketing is concerned. Even I could spin that so that that it looked like more of an advantage than 64bit capability which to be honest is a real hard sell as far as your average consumer is concerned.
You mean like the time I sent myself 22000 mails because the OS in question didn't have an implementation of sleep.
About four months ago I was asked by the Irish Department of Environment, Heritage and Local Government to provide a technical assessment of their implimentation plans for our nation wide Local and European Parliamentary elections in June (more in this previous Slashdot Article. In the spirit of openness I should own up to being an IT security specialist for a large US multinational (not MS). It's also worth pointing out for those that don't know that the Irish voting system is both complex (Single transferable Vote - Proportional representation) and extremely well understood by the population - we have it drilled into us virtually from the cradle and we love it.
The Good News (for us Paddy's). The system and plans they presented are generally very good for the type of system that it is. It's not open source but it has had some level of competant independant review. It's non networked, and the tallying systems are also non networked. It has already been trialled in some constintuencies in the last general election here with very favourable voter reactions. It reduces the counting time for a typical constituency from ~24 hours to ~ 2 hours. The bulk of that ~2 hours is the time taken to physically transfer the results from the tally machines (stored in redundant flash modules) back to the central count. Re-counts take minutes rather than days (we had 2 constintuency recounts take more than a week last time round). From a security best practice point of view they showed a sensible approach to securing the devices, the tallying machines and the physical\personel processes involved. An almost identical system (same voting booths but different vote tally code due to our specific electoral rules have been in use in Germany and The Netherlands for a number of years without any evidence of issues that I am aware of (but maybe someone here is). They take voting privacy very seriously - Irish constitutional case law has made it clear that a voting system cannot even theoretically allow an individuals vote to be known, that specific feature has had to be audited independantly
The Bad News (sort of). This system is electronic only - there is no provision for an independantly auditable "paper vote". This has been and is still under consideration but the response I got was that it would compromise the vote privacy ruling. The problem for us is that our voting system has inherent short cuts (ie hacks) in the transfer system that uses sampling to allocate so called surplus votes. This sounds a bit bizarre but it works, we understand it and above all everyone accepts it. The technical details of the problem are outlined well in this thread on www.verifiedvoting.org . Unless the paper votes and the electronic votes are randomised identically then paper vote counts will not tally precisely with the electronic tally. If the resulting vote is very close then the difference could be enough to change the election result. If both are randomised identically then by implication a voters actual vote could technically be identified - which is illegal. Of course the problem would go away if the electoral rules allowed for complete electronic counting (no need for the time saving hacks anymore) but until e-voting is proven that will not happen. It's an interesting dilemma and I was impressed that the government officials understood the problem as well as they did.
I had many other concerns which I voiced but I was far from un-impressed by these guys, particularly since most of them weren't tech heads. They were keen to talk and listen, had researched things very well and took on board much of what I suggested.
In the end they are going with the system more or less as it is but with lots of physical and process security rather than th