Posts by codebeard 38 publicly visible posts • joined 6 Mar 2010
The device key is actually stored in the secure enclave, which is essentially a tiny isolated computer on the SoC.
Yes, you're right. And no doubt the counter for the number of failed attempts is stored there also. I wonder if there is some way to trick the SoC into reading the counter as 0 every time, or induce a failure to write to the value.
I wonder if the flash memory can simply be copied into an emulator that can rewind after every pin attempt? No need to write anything onto the firmware itself.
Personally I think this is a reasonable request. If you "encrypt" your files with a 6 or so digit pin, that's more of an inconvenience than an actual attempt at security. For comparison, my password storage is encrypted with a random 25 character alpha + numeric + symbol password.
6 digits = 20 bits (approximately)
25 random characters = 155 bits (approximately)
The latter would take 4 x 10⁴⁰ times longer to brute force.
If anything, the low fraud rate in 2007 is more of an outlier in that UK data then any increase seen in 2008. In fact, bar 2007, it looks like the fraud in 2008 is exactly on the trend line. Also, the decreases in 2010 and 2011 (despite the graph saying an increase of 24% for 2011?) seem to indicate that the banks managed to adjust a little to the new system.
I suspect the same thing will happen in Australia. Maybe fraud will increase at first, but banks will improve their fraud detection algorithms. If I were a bank, I'd be building a social graph of bank accounts and transactions between them; transfers between distant nodes in the graph are more suspicious and could be combined with machine learning to flag and delay transactions suspected to be fraudulent.
Disguise encrypted data as bittorrent traffic? With torrent traffic taking up a huge chunk (~30-40%) of the internet's throughput, I think this would be incredibly effective. Although the encryption in bittorrent is fairly weak, there's so much traffic that it would be nearly impossible to decrypt enough of it to find the one or two pieces here and there which are actually PGP/whatever data in disguise.
Arts – nobody left undeleted data on the drives, 44.4 per cent had run a "quick" format, and 33.3 per cent had run a full format.
I think this is far too generous to arts students. The reality is that none of these students had stored anything on the drives in the first place. 33.3% of them had never even plugged their drive into a computer before.
> Personally, I think it would be naïve not to assume that they have every SSL certificate issued by every US-based certificate authority.
SSL certificates don't contain private keys. It doesn't matter if the government has all the certificates (which are publicly available anyhow). If you are doing it properly, the CA never learns your private key. You send the CA a certificate signing request which contains your public key, and they give you your signature. The private key never leaves the safety (hopefully) of your server.
there are some times when using an unsupported, unpublished API also carries the risk that the API will stop being be available
In other words, their policy on unsupported, unpublished APIs is exactly the same as for their supported, published APIs. You're lucky if you even get 14 days notice sometimes.
Why bother with complicated accelerometer data when you can just request location permission?
Something like 36% of all apps on the Android store request your location data (at least according to an article I read by Zscaler research). It's so common that only the most paranoid of users will hesitate to install an app that asks for it. Another common permission is audio/video, and combined with the common "run in background" permission allows much more worrying forms of surveillance.
The problem in my opinion is the lack of oversight users are given to see what apps are running and doing on THEIR phones. If you could easily see that your "calculator" app runs in the background 50 times a day and requests your location and audio recording every time, then you'd uninstall it. Especially if this were exposed better as part of the "battery usage" then I think average users would care about it more.
The VAST majority of apps should not need unrestricted access to run in the background. When they do run in the background they should be put in a sandbox with no access to hardware/sensors, and limited access to poke around the filesystem etc. Apps that want to background without a sandbox should trigger a notification e.g. "App X has recorded 22 seconds of audio"; clicking on it should give users the option of forcing the sandbox, uninstalling the app, reporting the app for malware, and permanently ignoring this kind of hardware access for this app.
I've done a bit of research into this myself, and what I found was that apparently the string from the "ISP Ver Check" is actually hard-coded into the kernel, so it's neither probing the hardware nor necessarily telling you the truth. The best info I can find is actually that all the Note 4s use the same camera hardware, but some have different image processing chips.
The only certain way to know would be a tear down, but to date I've only seen a tear down of one regional variant the Note 4, not the other regional variants.
... they want their insecure HTTP back.
Exploits like this are really only possible because so many websites don't support HTTPS in the first place. For example, this website. Without a plain HTTP page to inject code into, there is not a practical way for POODLE to operate. If the internet would please get off its backside and make connections encrypted by default (this is a post-Snowden world, after all), it actually wouldn't matter if we all used SSL 3.0 – there'd be little way to exploit it (at least without collusion between a site that the user has open and the evil people intercepting their network connection).
Having travelled in Korea, I can't begin to say how annoying those resident ID numbers are. You can't open accounts on websites, can't get a SIM card for your phone, can't make online purchases, can't go to some internet cafes etc without one. And you can't get one unless you are a citizen or have a long term visa.
In my home country you usually only need to give your name, email and address to buy something online or fill in a form. It's much better.
In an interesting counterpoint to NBN Co's research, US researchers the Analysis Group have found that American cities with fibre-to-the-home generate better per-capita GDP than those without.
It seems more likely that high GDP per-capita cities can afford fibre-to-the-home sooner, as oppose to the implication that having FTTP makes everyone more wealthy.
And remember, this was demanded of app devs before they would even start developing apps on Android.
Personally, I think this story is a little apocryphal. Furthermore, it's entirely irrelevant.
Regardless of any so-called commitments made to app developers in the past, Google should just say "in the best interest of users, and in a world increasingly hostile to user privacy, we are now giving users more control over permissions." Android already has a great market share (over 60%), and it would only increase if Google start giving users proper control over their privacy. And as time goes on in this post-Snowden world, user demand for this will continue to increase.
Google makes almost no money from developers. They make money from ads, and a little by taking a cut from play store sales. Users not installing apps means users not seeing those ads and not paying for those apps in the play store. It is in Google's financial interest to put users at ease by giving them the power to install apps they would not have otherwise installed due to security/privacy concerns. Furthermore, this has a double benefit of hurting their advertising industry competitors who are making dirty money selling contact data harvested from dodgy apps etc, because users will stop giving contact access to those apps.
If developers leave the market or make their apps unusable upon Google giving users more control, it is their loss and they know it. Android has a growing market share and developers would have to be idiots to just give that up.
There's already a specific Android permission for this "Draw Over Other Apps".
That permission is something unrelated. This article is about apps with no special permissions being able to intercept the whole activity, not draw over a specific part of another app.
And for the record, "draw over other apps" is very dangerous and should only be granted sparingly to apps you really trust. Unless I trust an app AND the app has a good reason for needing it, I do not install anything asking for this permission.
Even if you completely eliminate the side channel info leaks*, these kind of issues will remain as long as an app can hijack the running activity.
Can it be made so that apps require a special permission to start an activity while another app is running? (Unless initiated by activating a notification or an intent by the currently running app.)
If that's not possible, perhaps the change in app can be made more obvious in the UI. For example, if an app tries to start an activity while another is running, the old app could be shown to fade/zoom out to display the home screen for a fraction of a second, then fade/zoom in to display the second app? This could be accompanied by a hovering alert saying "Background process MyCoolGame is replacing MyBankApp". Sure, some users won't notice, but those that do will hopefully get the app reported. With increasing device resolutions, it may also be possible to show the current running app in the status bar (kind of like how a browser's URL bar mitigates against phishing attacks), which doesn't rely on the user noticing an animation.
*Some methods to mitigate these side channels are to disallow access to other processes /proc directories, and delay and/or reduce the resolution or of other readable info like network stats (e.g. network counters could be delayed by a couple of minutes, and only be accurate to 1MB increments unless the app is privileged).
Google Play has no approval process, so tests like this can't be part of it. :)
Google does have an automated process for scanning apps for malware. It sounds like SSL tests should be part of that. Fortunately it's quite straightforward to run each app in a sandbox and attempt to MitM any outgoing SSL connections. If the app doesn't immediately close the connection, it should be considered vulnerable.
Meanwhile, the BitTorrent protocol itself still lacks the basic ability to authenticate peers and trackers. You can just grab a list of hashes for popular torrents, connect to random torrent clients and start requesting files - even if those clients were using private trackers. Oops.
What's the odds that if some of the "metadata" and browsing history from David Irvine and other government leaders were brought to light, they might change their opinion about the virtues of this invasion of privacy?
Besides, any real threats to national security would already be employing countermeasures against this kind of surveillance; VPNs, encrypted messages, cheap prepaid phones, proxies, tor, etc.
No doubt after a few years, Google will take these 4 permissions and just roll them into 1, just like they have recently done with Android.
Google just does not seem to understand the idea of privacy.
It's enough for me to give all my email data to Google. I don't want to share every email I've ever had with third parties.
I would only use something like this if:
1. Users could override the permissions. If the app wants full access but I only give it read-only access, it can ask me nicely to increase permissions, but otherwise it should do its best to function anyway.
2. I could optionally set per-label permissions. So I could give an app full-access to emails labelled with "Newsletters" or something. Alternatively, an app could ask for permission to access emails matching a specific search query (e.g. "from:*@appcompany.com").
3. It were possible to see how much data the app had requested and how often, as well as the last N emails it has fetched.
*dons tin-foil hat and enters conspiracy mode*
The previous CTO and then CEO, Brendan Eich was a vocal opponent of the DRM extensions. But now that he's gone, ostensibly because of his unfashionable personal opinions which didn't impact Mozilla, it seems nobody at the helm shares his personal opinions (against DRM) which did impact Mozilla.
I wonder if there's a money trail from Adobe to OkCupid to help push Eich out...
Web browsers need to start reporting known security flaws to users visiting a site, by default.
I know there are extensions you can install for this kind of thing in Firefox or Chrome, but I think this shows the need for a installed-by-default warning system. Just like your browser warns you when you visit a site with an invalid/self-signed/expired certificate, it should check a database and warn when you visit a site with a possibly compromised certificate.
If enough users get a warning bar appear when they visit unpatched.com, some of them are going to complain to the administrator of the site, hopefully resulting in getting it fixed.
"Point 2 was DELIBERATE, at the request of the devs. Otherwise, they would never have been tempted to leave Apple's walled garden."
I'm not saying Android should have the same permission system as iOS. I just think they could do it better. Furthermore, the walled garden thing was more about what was allowed / not allowed in the app store.
Regardless of the reasons that Android started using this "all or nothing" permission system, it's time to change. All it's going to take is one or two high profile apps to be found collecting private data and that data to leak on the internet or something.
"Intents are usually only used when an app like Gallery is standard on Android. Things like barcode scanners can't be safely assumed to be there."
The solution to this is not to just give up and let every second app require the camera permission. The solution is a simple dependency model. The play store entry for an app could show if there are any other apps or generic intents it depends on, and encourage the user to install them as well. (With intents it could open a list of apps providing that intent, so the user could have more choice in some cases). If the user installed the app without the dependency, you can say when the app is opened; "hey, we need a barcode scanner [open scanner app in play store]".
"As for point 1, make the permissions too fine and you face a moving target as under the hood stuff changes from verdion to version, breaking lots of stuff."
Having too many permissions is a bad idea, but we have the opposite problem right now. It's actually easier to handle version changes when permissions are finer too; if an app compiled against an old API has ALLOW_A_AND_B permission, it can be automatically treated as ALLOW_A and ALLOW_B under a finer permission model, but this can't be done the other way.
Games don't need any permissions (like READ_PHONE_STATE) to pause when a phone call arrives. Android will call the app's onPause handler when another app (e.g. the phone call app) takes over, and they should handle that properly. There is nothing special about "receiving phone call" vs "some other important app is now using the screen" and the game should not discriminate between the two.
Games might say they use READ_PHONE_STATE to pause when a phone call arrives (which if true would mean they are poorly written), but the truth is that the ad libraries require it for... you guessed it, tracking your phone number, phone network and IEMI.
Android's permission model needs a major overhaul. There is some evidence to suggest that Google was working on small improvements (see App Opps which appeared in 4.3/4.4) but they later disabled the functionality.
There are three main problems:
1. The permissions are not nearly fine-grained enough.
2. Android doesn't provide a sensible framework for withholding permissions at installation or other times.
3. There is a culture of "roll your own camera / phone dialler / text messenger / QR code reader / etc" rather than using the Android intents system, and users don't realise they should complain about it.
The best example of the first problem is probably READ_PHONE_STATE. It allows an app to read not just your phone state (i.e. in a call or not in a call), but also your IEMI, mobile phone number, mobile phone provider, and the mobile phone numbers of other parties if you're in a call. This is required by almost every game and app in the play store. That's a lot of apps which I have to give my phone number if I want to use. This should have been split into several separate permissions; READ_CALL_STATE, READ_IEMI, READ_DEVICE_UUID, READ_PHONE_IDENTITY, and READ_CALLER_INFO. In this case, READ_DEVICE_UUID would be relatively benign (they wouldn't have the IEMI but just a randomly generated device specific UUID suitable for tracking ads across apps on the device) and READ_CALL_STATE would be nearly completely harmless. However, no game should require READ_IEMI, READ_PHONE_IDENTITY or READ_CALLER_INFO and these should be red flags.
Another example of the lack of fine-grained permissions is that access to the internal/external SD card is pretty well all or nothing; if you can read photos from DCIM/ you can also read anything else which any app has put on there. For example, if an app stupidly stores a secret key somewhere in its "own" folder on the SD card, many other apps can read it. There have been some changes to this recently but it's still far from a sensible system. A much better system though would be if very few apps were expected to need READ_EXTERNAL_STORAGE / WRITE_EXTERNAL_STORAGE, but those apps could then pass file handles to other apps through intents. So, a "file manager" app could read and write any of the files, and then pass a read-only or read-and-write file handle to another app, like a document editor. The document editor would not be able to read/write the files directly, but would need to use intents to receive a file handle from a trusted "file picker" app. That way I know that SillyPhotoEffects app can't go reading things I didn't intend it to. For common things like photo viewing apps, I think the best thing would be if they requested a standard application-defined permission like com.android.filemanager.permission.READ_DCIM, which would allow it to interface with FileManager and effectively borrow its permissions to read the photo directories (but not other files).
The second major issue is that there is no sensible system to disable permissions. If an app is installed, it can in theory expect that all of its permissions have been granted permanently. A better system would be if any permission could be withheld at any time and the application would need to be written to handle this. When an application is first installed, the system could ask the user which of its permissions to enable. Relatively safe permissions could be on by default, and potentially unsafe permissions could be off by default with a warning about possible impact on app functionality. Apps could detect which permissions were being withheld and request the user enable extra permissions if needed (e.g. "ExerciseLogger needs to access GPS to track how far you've run. [Option App Permissions].") If your FunFruitSlicer app refused to work without camera permission you'd realise it was just spyware and use the handy uninstall link from the App Permissions screen.
Having the ability to withhold any permission would also solve the problem of "we'd better ask for every permission in version 0.1 in case we want to do XYZ some day." You never know when your government medicare app might need to start taking photos, apparently. Instead, developers could add new permissions to their app manifest with any future update without blocking the update path; they would just be withheld until manually enabled by the user (which the updated version of the app could kindly ask the user to do).
The last problem is really obvious with apps like this Department of Human Services. Almost no apps actually need direct access to the camera or phone dialling or text messaging. If they want to have a photo of something, they don't need the CAMERA permission; they can just use the MediaStore.ACTION_IMAGE_CAPTURE intent, which fires up an app which actually does have the CAMERA permission and which will return a photo to the calling app after (if) the user takes the photo. Similarly, if they want to place a phone call, the app doesn't need any permissions, it should just use ACTION_DIAL which will open a dialler with the given phone number and wait for the user to initiate the call.
The problem with this culture of permission creep and "roll your own X" is that users now believe it's perfectly normal for apps to request 20 different permissions, rather than for them not to need most of those permissions when the intent system works just as effectively. Fixing this issue is the hardest because it involves changing users' expectations, but if the architectural problems are fixed first then hopefully over time people will learn to push back against apps that ask for more than they need.
Isn't it going to be significantly harder to secure an offshore nuclear power plant?
What if a well organised terrorist group attacks from sea and steals the delicious enriched uranium? It would be hard to mobilise any kind of military defence of the platform. Or if during a war your enemy fires a torpedo at it (which can bypass all your advanced air defence systems because it's underwater)?
"And, strangely, the alternative pushed is this new-fangled perfect-forward-secrecy (only available with Elliptic Curve from what I can see with OpenSSL), that's still new, unknown and (security-wise) basically untested."
You can implement PFS without using ECC, but just with standard Diffie-Hellman. I'm pretty sure both options are available in OpenSSL. Anyway, it's just an extra level of protection, it really can't make things worse.
Many changes to law involve shifting the boundaries of what is and is not a legal right. And most legislative changes only affect a minority of people, who may perceive it as harm. And everyone is legally allowed to support legislative reform in accordance with their opinions. And this happens every week and nobody makes a huge fuss about it, unless it happens to be the politically correct litmus test of the day.
For example, I might support a law which would make smoking illegal within some distance of all public hospitals. In effect, I would be supporting legislation which would *remove* the legal rights of the minority who choose to smoke outside public hospitals. Furthermore, stripping them of these rights may "harm" them, because they might be fined if they continue smoking there, or might need to walk further or go to a private hospital instead. My point is not that smoking is the same as gay marriage, but that just because legislation may cause perceived harm to someone or revoke previous legal rights should not make supporting the legislation a thoughtcrime.
"I don't vote for politicians whose views I detest."
"I won't support a company led by someone whose views I similarly detest."
I vote for politicians based on their *policies and competence*, not based on their *personal views*. There are plenty of politicians who have voted against their own personal views in order to best represent their constituents. Furthermore, how do you truly know what anyone's real view is about anything - you might be voting for someone whose views you really do detest, but not realise.
Similarly, I support a company based on their *product and actions*, not based on the *personal views or even private actions* of any of their employees (CEO or not).
Actions speak louder than words, and I am not the thought police.
What matters here is not the personal views of Mozilla's employees (even the CEO), but rather Mozilla's product and corporate actions. And their corporate actions included written policies in support of gay marriage, and Eich understood this and was prepared to enforce those policies in the company even though they may have not been in line with his personal opinion. I respect any CEO who has the integrity to be honest about their views and yet still act in the best interest of the company and its stockholders even when it's not 100% in line with their personal beliefs.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
