Pretty basic question. When I create a key using google KMS, is that key public or private?
I need to develop an asymmetric key pair using HSM for a project, someone asked me, and I'm not crystal clear on that. Any help?
When you create an asymmetric key using google KMS both the private and public key are created. To retrieve the public key you can use the GetPublicKey API call. https://cloud.google.com/kms/docs/reference/rest/v1/projects.locations.keyRings.cryptoKeys.cryptoKeyVersions/getPublicKey
You cannot retrieve the private key from Cloud KMS. You can only access it via API calls for AsymmetricSign or AsymmetricDecrypt.
Related
I need to protect a group of user’s data, i.e. to facilitate multiple invited users to read and contribute protected data.
My understanding is that I need to implement the following design:
1 . Each user gets authenticated with Firebase Auth (OAuth2 or email/password).
2 . Each user creates a public/private key-pair (How?). The public keys can be shared in Firebase. How to store the private key? Seems natural to store it in Firebase in encrypted form (passcode protected), but how?...
2a. Either the users must manually store the passcode in e.g. a “personal password manager”. Password protect private key
2b. Or could the passcode come from e.g. the OAuth 3rd party?
3 . Encrypt/decrypt data (support user group). Multi-user-data requires an extra layer for having a common (symmetrical) key (How?), so all invited users can encrypt and decrypt data. The group manager stores this common key in Firebase to all users, using their individual public keys. Virgils story about the Creator.
So does the above requirement make sense(!), and how to get around compliance? How to document such security measures? Protecting your customer’s data might make you sleep at night, but you also need to convince the future customers that data will be safe.
I wonder why Firebase does not have a guide on all this, to safely facilitate GDPR. The topic seems such a show stopper nowadays.
All constructive input are highly appreciated!
I'm trying to integrate a custom IdP for access to OpenSearch dashboard and in the process of creating request signing. For this, I need to create private key based on the algorithms mentioned in request-signing with or without a pass phrase.
If I understand it correctly, for request signing I need private key in any of the algorithms mentioned in the link (eg: RSA_SHA256). But, so far I'm unable to figure out how to use openssl or any other CLI based tool to create private key based on the algorithms mentioned in the link above ? Any help on how to create private key is much appreciated.
Regards,
Santosh
Usually, this story goes like "client encrypts using public key - server decrypts using the very-safely-stored private key'.
Well, I have the opposite issue.
In a mobile app, I am using a web service library, whose API requires 2 secret keys from my personal account of that service. Anyone having access to these 2 secret keys can basically use them to call the same service's APIs as if it was from my app. So, I definitely do not want to embed those keys in the app as a decompilation might easily spoil them.
So I thought I'd store those keys server-side, and send them encrypted with a public key to the app. Then, the app would decrypt them using the private key stored in the app itself.
I know it's still not secure, but at least, a simple man-in-the-middle attack or a binary decompilation analysis will not scream "Service API keys here, come and get them!". The intention here is just to make it harder for someone to get a hold of those keys.
Do you think this would be a good idea? Do you have any other alternatives?
The secure way to handle you private keys is to keep them on the server and never release them to the client.
For each approved action create a server endpoint (e.g. an AWS Lambda). The server endpoint knows the private keys, but the app just knows where the endpoints are. This restricts the functionality to only what you approve, but the endpoints themselves can be discovered and could be used by other people without going via your app.
The endpoints can use some authentication such as JWT Bearer tokens (see https://www.jsonwebtoken.io/ ) to ensure they are only used by the application, but this requires server side knowledge of who is registered with the app.
Alternatively, if the private keys cannot be used for actions you do not want your application users taking, is it worth protecting them?
There are good reasons for aiming to make things hard but not secure, for example, the cost of creating all those endpoints I mentioned vs the risk of someone abusing the private keys. Unfortunately that means someone agreeing to a compromise and I can't advice you on the best compromise.
I am following this guide: https://jamesmontemagno.github.io/InAppBillingPlugin/SecuringPurchases.html
to try and perform receipt validation. It mentions that I must implement this interface: IInAppBillingVerifyPurchase. But it also mentions for Android that I must get a public key from somewhere and split it into three parts. My question is where do I get this public key from?
This seems to be provided by the Play Console of your application.
To help ensure the integrity of the transaction information that is
sent to your application, Google Play signs the JSON string that
contains the response data for a purchase. Google Play uses the
private key that is associated with your application in the Play
Console to create this signature. The Play Console generates an RSA
key pair for each application. You get this response JSON using the
getOriginalJson() method within the Purchase class.
Note: To find the public key portion of this key pair, open your
application's details in the Play Console, click Services & APIs, and
review the field titled Your License Key for This Application. The
Base64-encoded RSA public key that is generated by Google Play is in
binary encoded, X.509 subjectPublicKeyInfo DER SEQUENCE format. It is
the same public key that is used with Google Play licensing.
When your application receives this signed response, you can use the
public key portion of your RSA key pair to verify the signature. By
performing signature verification, you can detect any responses that
have been tampered with or that have been spoofed.
source: https://developer.android.com/google/play/billing/billing_library_overview#Verify-purchase
Hi Hyperledger Experts:
In some cases, some organizations in a channel have the requirement to encrypt their data on the fabric network. Please refer to https://hyperledger-fabric.readthedocs.io/en/latest/chaincode4ade.html#chaincode-encryption . And the AES encryption key and decryption key are needed.
So there is a need to store some organizations' encryption key and decryption key. The fabric documentation also mentioned "If you encrypt the data then you will need to provide a means to share the decryption keys". Please refer to https://hyperledger-fabric.readthedocs.io/en/latest/Fabric-FAQ.html
So the question is: what is the advisable way to store the AES encryption/decryption keys? Where to store them?
Apart from fabric network, do we need a separate centralized database to store them? Or can we directly store them on fabric network, and only let specified organizations to get them? Thanks very much!
I'm not an expert in data security but I believe your problem can be solved using Private Data present in hyperledger fabric framework itself.
It is confidential data that is stored in a private database on each authorized peer, logically separate from the channel ledger data. Access to this data is restricted to one or more organizations on a channel via a private data collection definition. Unauthorized organizations will have a hash of the private data on the channel ledger as evidence of the transaction data.
Refer to docs to understand how to use this to store your AES keys.