Microsoft provides a method to get an ASHWID (App Specific Hardware ID) which has many components, one of which is some kind of BIOS ID.
http://msdn.microsoft.com/en-us/library/windows/apps/jj553431.aspx
Does that BIOS ID change if the user upgrades the BIOS on their computer?
RANT:
I don't understand why Microsoft makes getting a unique ID for an OS installation so complicated for Windows Store Apps. Android is so simple, when the Android OS boots the very first time they generate a GUID (see http://developer.android.com/reference/android/provider/Settings.Secure.html#ANDROID_ID) that never changes. Why doesn't Microsoft do this?
First of all, that value changes with factory reset in Android.
Second of all, try checking out EasClientDeviceInformation.Id. It uses a combination of the MachineId (local user group SID), the UserId, and the Package Id, but doesn't give you the whole thing.
This is good because Thirdly, giving devs access to use them directly to generate things like crypto keys can lead to other apps getting your apps keys, like has happened on many iOS devices. By limiting what device id's you can use, they're making it so that you must use a system resource that is literally only accessible from inside of a given application with a given Id from inside that user's account. The Windows Store is very strongly sandboxed for exactly this reason. While it can be a pain sometimes, it makes the platform much more secure, which is a huge boon.
Related
According to the Mac App Store Review Guidelines:
2.4.5 Apps distributed via the Mac App Store have some additional requirements to keep in mind:
(i) They must be appropriately sandboxed, and follow macOS File System Documentation. They should also only use the appropriate macOS APIs for modifying user data stored by other Apps (e.g. bookmarks, Address Book, or Calendar entries).
...
(iv) They may not download or install standalone apps, kexts, additional code, or resources to add functionality or significantly change the app from what we see during the review process.
(v) They may not request escalation to root privileges or use setuid attributes.
Sandboxing already precludes the use of APIs such as AuthorizationCreate(), and anyway, item (v) is pretty clear.
Certainly an app like, say, Parallels (MAS link) can't be coded without ever resorting to privilege escalation. Indeed, the regular (non-MAS) Parallels app installs at least 3 kexts, one of them being the hypervisor, without which I believe Parallels would be absolutely useless. So they are clearly violating these rules.
If a developer wished to write an app that, like Parallels, needs privilege escalation and is completely useless without it, how would the developer go about bypassing these restrictions? Or is it just a question of being big enough that Apple will turn a blind eye to this during the review process? Can you request an exception to Apple?
No comment on the App Store policy issue (unfortunately), but I can answer your question about Parallels. The version of Parallels on the Mac App Store does not use a kext, nor does it need to. The Hypervisor framework makes it possible to write a Parallels-like application without needing root privileges, or writing and distributing a custom kext (which requires separate approval by Apple). The Hypervisor framework is also usable from sandboxed apps. I believe this framework was created specifically to workaround this problem. Hope this helps!
It has come to my attention that code signing certificates are from now on required to be paired with physical tokens.
The Minimum Requirements specify that CAs shall ensure stronger protection for private keys. As such, all Code Signing Certificates, not just Extended Validation level, will require a USB token starting on January 30, 2017. With this, all New and Renewal Standard Code Signing orders will be sent a USB token to store the certificate and protect the private key. Also, all standard Code Signing products except for EV Code Signing will be integrated to one “multi-platform” Code Signing Certificate.
Note: Reissues of existing Code Signing Certificates (issued prior to 30 January 2017) will not require a token right away. However, this is subject to change.
As someone who uses a cloud-only workflow, this raises an obvious concern for me - I cannot just plug this USB token into "the cloud".
Do I understand it right that I will from now on need to set up a separate on-premise code signing process? Or is there some possibility remaining for signing code in the cloud? What are the expectations I should have for working under the new rules?
Based on the article you linked it sounds like you will absolutely need to provide your build system access to a USB key in order to sign your artifacts. As you mention the obvious solution (and probably what Microsoft is attempting to encourage) is to set up an on-premise build system that gets used exclusively for code signing.
From a security point of view this is probably the best option since you could harden that machine both in terms of software but also in terms of hardware (e.g. locked in a closet in your work area). But this might also not be realistic depending how your build system is set up.
Your other option is to use a USB forwarding solution to forward the USB key to your cloud environment. There are a lot of ways to do this and the best one is going to depend on what you're building and on what operating system(s) but here's a rundown of some options:
Linux systems - USB/IP - This is a kernel module and userspace application provided with a good number of Linux distributions (it's a mainline module, but not always included). This lets you take a local USB device and forward it over the network to another Linux machine. I've had pretty good luck with this but setting it up the first time can be a little tricky.
Windows Systems - RemoteFX forwarding over RDP - On newer Windows systems (Windows 10, Server 2012 R2+) Remote Desktop supports USB redirection natively. You can simply forward the USB key through a RDP session. This would require you to remain connected at all times while building though.
Windows Systems - Third Party Software - There are several third party USB forwarding solutions available. For instance this one. Some of these have the advantage of being able to run without requiring an active desktop session.
The gotca with all of these solutions is that if the USB token is designed to actively prevent this (or is somehow otherwise incompatible with forwarding) it may not work. Some license keys for instance will check to make sure the timings to/from the computer are within a certain tolerance for instance. In those cases the added latency from the cloud to your machine would cause the token to not work. It'll all depend on the USB key you get sent.
The whole point of policies like this is to prevent you as the keyholder from accidentally losing control of your key material by giving you something you must physically possess in order to use your key. Cloud build systems are convenient but tend in general to have a much wider security landscape which makes securing keys trickier than on-site systems. It looks like Microsoft and your CA are attempting to prescribe how keys are being handled.
I have two applications already submitted to the marketplace and just now I realized that they have the same ProductIDs in the WMAppManifest and AssemblyInfo files - so I can not have both of the apps installed (deployed) to the emulator at the same time.
If during the submission process this ProductID remains the same, then I am afraid that users will not be able to install both of my apps at once. So I guess my question is: does it really matter what ProductID I specify in those two files? or does the submission process take care of it and generates a truly unique GUID?
The product Id is assigned when you create the app in the app hub. For WP7.X especially, most of what you put in the WMManifest.xml is over/re-written as part of the certification process.
The bigger issue you are likely to hit is that you can't load multiple apps on a device with the same ProductId so if you ever want to load them in the same emulator instance or on the same physical device you'll need to change one of them.
am using c# vs-2005
am trying to setup & deployment of project and did it very simple by adding assembly and prerequesite of the project on setup properties.
but i want to deploy it by professionally like to first read bios of user system and detect the HDD serial. after detaction of HDD Serial i want to generate my own key to allow user to do the setup.
Narration :- " I want to run my application on specific HDD. For new HDD user Shoul Contect Me"
suggest me proper way or any proper coding will be highly appreciated.
There are an number of software licensing/activation systems available, we use Nalpeiron and have come across so many issues with various system configurations, that I wouldn't dream of trying to develop something like this yourself.
Primarily we use it for online activation, but you can do USB key dongle, phone, email, etc. depending on your exact requirements.
There is a Windows program which is downloaded after entering a valid serial in a web page. Now, I want to limit the user to install the program only on one single PC, the one he or she installed for the first time.
I need some advice on creating a such system. Thank you.
P.S. Serial key must be entered on the web page instead of the installer.
Sounds like you need to create a downloadable activex control program that will run on the client's machine in which it will interrogate:
MAC of network adapter
Windows Version, including SP
Hard disk serial number
Processor make and CPU type
And relay the information back to the website, then generate the key, and attach the key to the download installer and permit the user to download the installer in which the key is then read in at run-time and checked against the machine that is running on.
The only thing is the ActiveX must be written in C/C++ as you cannot do it on the .NET language as that is assuming the client's machine will have the runtime installed which IMHO is a dangerous assumption.
Hope this helps,
Best regards,
Tom.
The usual solution is:
Create a hash describing the system (don't know the exact way to get it though, GIYF) & combine it with the serial, so when the user installs the program he has to enter the serial, then gets a key he has to enter on the website which splits the entered key into the serial and the system hash and checks if the system hash and serial match the stored ones and then returns another key (or an error if the serial was already used) he has to enter into the program.
Using the Mac Adress as a system key is not a good solution as it can easily be faked.
Base the serial number on some hardware configuration. If the hardware changes, then invalidate the serial number. Microsoft windows uses this type of approach during the activation of the product.
Hope this helps some.
If you write a custom installer then you could send an acknowledgement to your web server upon successful install that sends a serial # generated from the hardware, and the serial # they used to download the file.
Then if you find the same serial # but a different hardware serial, you can send a response back saying that you could not activate the software...
EDIT
Here is some info on getting hardware info (assuming a .NET environment, but you can find similar for the environment you are using).
You could try blocking the key on install and unblocking the key when they uninstall. That way they can only use the key once between each uninstall.
set up a web service and database ... they have to validate to be able to install. the problem with your model at the moment is that you are protecting or hiding your software behind the server. You want peopel to have the software even if they cant use it (usually). the serial key stage should be there to unlock the software at runtime.
Its the only model that works for computer games.
You need to poll various pieces of hardware to generate a guid, hash it against a product key and you have a reproducible yet complex and hard to forge piece of data.
http://edn.embarcadero.com/article/26040 A link to the .com interfaces to get at the guids
an alternative would be to use something like sysinfo or dxdiag and save the rseults to a file ... hash it and use that as the serial. A lot less coding involved - but a bit messier.
Store this and issue the installation key - easy to spot and manage reinstalls then.
Ie you really don't want to go 'computer says no' - its really a marketing opportinuty