I want to use Azure Media Services to provide the licenses for content protection. I created the ContentKey using the PHP SDK, and got the license URL for Widevine. I'm using packager in my side to encrypt the video.
My problem is (mostly because of ignorance) that I don't know where to find the value for the parameters "--signer", "--aes_signing_key" and "--aes_signing_iv". I read in some tutorials that these values are provided by Widevine, but in my case I assumed that were provided by Azure.
It's not an issue with PHP or packager. Even using the REST API I don't know which information correlates to "signer" "signing key" and "signing iv". This information is required even by other platforms like bitcodin and other packagers.
If you are using your own packager, you only need to configure the common encryption key and Widevine License template with us, you will obtain a license URL and KEY ID as return, and you can put those value into your packager.
You don't need to configure AES envelope Key, which is for AES 128 clear key encryption. That's another service that we offer.
Feel free to reach out to me at yanmf#microsoft.com if you have more questions. I am the PM on this Widevine services on Azure. We will help you.
Related
I'm trying to develop a Webapp that would allow users authenticate with their Google Account and store some information and files on their Google Drive.
It would be a static html/js page with no backend.
There is a quickstart example here:
https://developers.google.com/drive/api/v3/quickstart/js
It works fine but I am wondering if exposing my Client ID and API Key to everybody like in this example could not be a security problem. Anyone could use these id and key in their own app.
What do you think?
As per Changes to the Google APIs Terms of Service, you are asked to keep your private keys private.
Asking developers to make reasonable efforts to keep their private
keys private and not embed them in open source projects.
The author of that post was contacted and the exchange was made available on DaImTo's blog. This is a part of the reply:
Yes, you are not making your personal data available to them. You are,
however, allowing them to “impersonate” you in Google’s eyes. If our
abuse systems detect abuse (say, should someone try to DoS one of our
services using your key), you run the risk that they would terminate
your account because of it (and please note — they wouldn’t just cut
access to the key, they would shut down your console account).
We want to migrate HSM keys from Thales paysheild 9000 to Azure Key vault. We would like to know if this migration is supported and if supported, what’s the migration approach and use cases where customers have already migrated to Azure. We have gone through the article https://github.com/MicrosoftDocs/azure-docs/blob/master/articles/key-vault/key-vault-hsm-protected-keys.md, it talks about Thales nShield family but we are using https://www.thalesesecurity.com/products/payment-hsms/payshield-9000
Thanks in advance.
Excellent question, as Dan suggests you should contact Microsoft for clarification, but unfortunately I don't think it's possible.
Recapping, as I'm sure you are aware the purpose of HSM's is so that the keys are not exportable.
Microsoft (and I assume Thales) supports key backup: https://learn.microsoft.com/en-us/rest/api/keyvault/backupkey but it can only be restored to the same geographical area.
In the article you supplied it mentions "Key Exchange Key" in each geographical area, which I assume will mean that Microsoft will be using a different key to that of another install of an HSM.
Having said this I'm not a general HSM expert, these are just links I have come across over time using KeyVault.
Please do contact Microsoft as I would to be interested if this is possible, please post an answer once you have heard back or a Microsoft employee can perhaps answer directly.
On the Thales literature it states:
"With nShield BYOK for Microsoft Azure, your on-premises
nShield HSM generates, stores, wraps, and exports keys to the
Microsoft Azure Key Vault on your behalf"
http://go.thalesesecurity.com/rs/480-LWA-970/images/Thales-e-Security-Microsoft-Azure-UK-sb.pdf
Interestingly it says generates / stores which suggests a pre-created key could be migrated. However on the contray I'm guessing the export must happen using the "Key Exchange Key" and stored in both on-prem and exported for Azure at the same time, not on-prem first, in the BYOK process.
This blog post has keyvault team's contact details if it helps: https://blog.romyn.ca/key-management-in-azure/
The migration of important keys, that are encrypted under current LMK on your Thales payshield on premises, is very straightforward process:
1- Use console command GC to generate new ZMK in a clear format component, this will be done by using key type to be 000 which is ZMK key type, and also to choose clear format components option use letter 'x' in GC command steps.
2-Repeat the GC command above 3 times to generate 3 different plaintext format components of the new ZMK.
3-Now, at your payshield 9000 HSM, use the console command FK which means Form Key from components, the result is the new ZMK encrypted under old LMK.
4-Use the command KE ,which means export key, to export the important data encryption keys (DEK), such as ZPK for example, which is encrypted under old LMK to be encrypted under the new ZMK. Note: in KE command here use key type to be 001 which is ZPK key type.
5- Now you need to manually distribute the same new ZMK to the other party that you are going to migrate to.
6- You can do this manual distribution to such an important key (new ZMK) by sending the 3 different plaintext format components, which you have generated earlier in step number 2, to three different security officers at your corporate, and for security reasons, no one can have the 3 components all together.
7- On the other entity that you wanted to migrate your keys to, which is Microsoft Azure Key Vault cloud service, Azure is offering securing your keys in a hardware HSM environmental of nShield type, which is general purpose HSM and it is not specific in payment transactions like Thales payshield HSM.
8 - Refer to Microsoft Azure key vault documents, to know how to form the new ZMK of the 3 different plaintext format components that you have generated before, and refer to nShield manuals also to check the command which is responsible for importing keys.
9- Now, your important keys such as ZPK which was exported under new ZMK, are now imported under the same ZMK, and finally stored encrypted under the new LMK of your nShield provided cloud service.
I am a beginner web designer and I am struggling to find relevant information online as to how I should go about managing my API keys for clients! I would really appreciate any tips or insights on how I should go about this!
I hold my own google account and already have my own API key (Javascript API) for my own website. Although, when creating websites for clients, is it okay to use the same API Key? Or should i create a new API Key for each client in my own account (creating new "projects")? Or should i be creating a google account for each client and then creating each client an API Key through their own account?
I also know that there are usage limits on API Keys so I want to ensure I dont exceed these if using one API for multiple sites. How can I monitor this?
Looking for any advice on the best and most efficient way to go about this. I do not know too much on how API Keys work!
Much appreciated :)
I will be using Google API as an example. Yes, you should always Create a new project for each client there are a multitude of reasons why you should do this and you already mentioned some of this
API query usage limit.
Separated client billing & usage breakdown for each project.
Security and revocation of compromised APIs.
Restricted security profiles, domain whitelisting, IP address, device usage etc..
Access management and role management.
Traffic and analytical reasons.
Creating credentials
Depending on your organisation needs and project scale, for us, we Create credentials (API key/ OAuth ID/ Service Account Key) for every platform the key will be used. For example, if we are developing an e-commerce website that comes with an app, we would issue 3 keys. (1 for web, 1 for Android apk, 1 for iOS app). This allows us to fine tune the access permissions and let us track usage.
What works for you?
If you are a freelancer or work in a small enterprise, the least you should do is separate every client by projects. There is no need to create a new Google account for each project. (You can always transfer ownership of projects to another account if your client requests at a later time)
The above screenshot is how we categorize items in our account, for each project we are contracted for (could be the same client) we will create a separate project entry.
How secure is the local data
ApplicationData.Current.LocalSettings
storage used in Windows 8 Store Apps?
This application data storage article says nothing about security, neither does this one.
Can this data be manipulated from outside of the app?
I looked at the location of the data
C:\Users[username]\AppData\Local\Packages[package_namespace]\LocalState)
but did not find it. Where is it saved exactly?
I'm trying to asses the security of this storage mechanism to decide whether I can store security-critical information there.
After some more investigation I found:
http://lunarfrog.com/blog/2012/09/13/inspect-app-settings/
The data is stored in
C:\Users[username]\AppData\Local\Packages[package_namespace]\LocalState\Settings\settings.dat
which is a Windows NT registry file (REGF) which can be openend with the registry editor and can also be manipulated.
Meaning, local storage is NOT safe.
If there is no other way, encrypting the data and obfuscating the keys is a possibility.
If it's user credentials that you want to store, take a look at PasswordVault class. Otherwise use DPAPI as you already suggested yourself.
This application data storage article says nothing about security, neither does this one.
Can this data be manipulated from outside of the app?
That storage is similar to iOS's Core Data. Its essentially untrusted input unless storage is protected (below the application level). Even if the storage is protected with encryption, its likely not authenticated so its subject to tampering.
If there is no other way encrypting the data and obfuscating the keys is a possibility.
On Windows Platforms, the standard way to protect sensitive data is to use the Data Protection API (DPAPI). Use DPAPI with the user supplied secret (the additional entropy in the APIs) for the best protection. You store the DPAPI'd data with the user's profile, in the registry, or on the filesystem. See, for example, Windows Data Protection, How to: Use Data Protection, and Data protection API (Windows Store apps). Michael Howard and David LeBlanc have a good treatment of the subject in Writing Secure Code, Second Edition. See Chapter 9, Protecting Secret Data, beginning on page 299.
If you want database like encryption, look at SQLCipher. It uses authenticated encryption, so it provide confidentiality and integrity. Windows 8 supports native libraries, including on their phones (see, for example, Native code on Windows Phone 8).
Is it okay to put your Google Maps API Key into your source code and publish it?
Others could take it and misuse it, but I don't want every developer / user to get their own API key and type it in somewhere. If the owner of the key is responsible, should I create a new google account for the project? (The project is a desktop application in Objective-C and a small developer tool.)
What would be the best way to make this convenient?
I don't think it's legal, but even it were, it's technically impossible, because the Google Maps API Key is tied to your domain name. Google will check the referrer of the HTTP request to validate the key.
The key isn't secret anyway: simply viewing the source of a website using Google Maps reveals the API key.