I'm beginner of solana programming using anchor. Now I have no clear understanding about these items.
**Program, Account, PublicKey, Keypair**
Appreciate any help to understand what these are and relationship between each other.
All of these terms can be found in the terminology section of the Solana docs at https://docs.solana.com/terminology
Program: The code that interprets instructions.
Account: A record in the Solana ledger that either holds data or is an executable program.
PublicKey: The public key of a keypair.
Keypair: A public key and corresponding private key for accessing an account.
Check out https://solanacookbook.com/ and the Core Concepts Section
Related
I am thinking about storing secret in blockchain. Although there is some specific blockchain dealing with it, I would like to see the feasibility in ethereum.
The idea is to store the secret as a state variable in encrypted format and the accessibility of this variable value is restricted to someone only. My question is, since blockchain is open and everyone, if someone is really skillful then he/she could read the value of the every variable. Do you think, or what is needed to do further, to make the value of the state variable secured enough?
People who own the machine running an EVM full node will have access to that variable. That accessibility limit is pointless in regards of keeping the data secret.
You could store encrypted data on-chain. But you need to keep the decryptor off-chain. E.g. you AES-encrypt a piece of data and post it on-chain, but you keep hold to the private key.
I should point out that an ethereum wallet, aka a secp256k1 keypair is capable of data en/decryption. You can encrypt data using public key, post it on-chain, and later fetch then decrypt with your private key, which is of course off-chain. Read more here.
Can somebody please clarify how DDA protects EMV cards against cloning
From what I have learned so far a random unique number is generated by terminal and sent to card
Card will generate a Private/Public key and then sign the the card data with private key and send it to terminal for verification
How does this protect against cloning ?
Card will not generate private and public keys. Private and Public keys are encoded into the chip during personalization. First you need to understand what the terminal and card have in hand to understand this. Go through this answer.
Now that you know where each keys come from, during DDA, using the ICC private key, card will generate a certificate, and terminal will validate the certificate using ICC Public Key.
Detailed process is explained in EMV 4.3 Book 2 Security and Key Management, section 5 and 6. Download from here . Start reading from SDA and have the basis clear.
I'm trying to compute digital signature RSASSA-PSS with sha256 for my IdentityIdentificationData (ASN1).
Directory file address 0x3D00
Aplication ID A000000061123A22738F4421
Private key folder 0x2F01
My ASN1 encoded hex data after sha256 encoded:
860c30a5f2b254ee92cbd3ec5c4282a940853aaef5f36d50ca20050637aaf4b0
I'm sending this command after SAM pin verified
MSE:SET
002241B606800191840110
SW1SW2:9000
Select File
00A40800043D002F0100
SW1SW2:9000
PSO: Compute Digital Signature
002A9E9A20860c30a5f2b254ee92cbd3ec5c4282a940853aaef5f36d50ca20050637aaf4b000
SW1SW2:6982
I'm a bit new on smart cards. How can i solve this problem. What is wrong or missing.
My SAM don't want to algorithm identifier for RSASSA-PSS.
6982 means: Security condition not satisfied
You should probably send the VERIFY PIN command directly before the PSO: Compute Digital Signature. Signature generation generally has very high requirements with regards to PIN, because the user has give consent for each and every signature. Hence the PIN may be invalidated by each command, especially if that command is an MSE:SET command. Selecting a DF by name may also influence the security environment.
So try the following order:
SELECT by Name (AID)
MSE:SET (for digital signature)
VERIFY PIN
PSO:COMPUTE DIGITAL SIGNATURE
The signature may also be depending on other security related objects such as an authentication key, for instance one used to setup secure messaging.
Can you check the access condition of RSA_Sign key ? If the access condition is NEVER then you wont be able to sign with this key. So in such case, SW 6982 make sense.
002241b606800191840181 mse:set is worked on me.
I am trying to understand the key high level details behind verifying trust when downloading an archive.
This is my understanding of how it could be done:
On the Software Developer side:
Obtain a certificate from a public CA like verisign
Generate a hash of your archive and then encrypt this string using the private key from your certificate, this is the "signature"
Host the archive for download, along with a separate file which contains the public key from your certificate + the signature generated in step 2.
On the (user) client side:
Download and unpack the archive, download the signature + public key file
Decrypt the downloaded signature using the downloaded public key, save this value
Iterate through the public root certificates embedded within your operating system. For each root certificate, decrypt the signature value and compare the result to the result in step 5.
Once a match is found in 6, you have verified that the author's private key descends from the chain of trust of the CA which you found matched in step 6.
This all assumes that the software developer used a CA for which we have an embedded root certificate in our clients OS.
Questions:
Is the above method sound, or am I overlooking key details?
Given a blank slate client that you control, if I wanted to combine the public key + signature + archive into a single file that I could make the client understand and parse, are there any widely supported formats to leverage for organizing this data?
Aside from being a little too specific on Developer (2) (that describes how RSA signatures work, but ECDSA is perfectly well suited to this task) that sounds rather like Authenticode minus some EKU restrictions. This leads me to ask "why not use Authenticode signing?".
The structure I'd consider is the PKCS#7/CMS SignedData format. It can describe multiple signatures from multiple certificates (sign it ECDSA-brainpoolP320t1-SHA-3-512 for anyone who can read it as well as RSA-2048-SHA-2-256 for most of us, and DSA-1024-SHA-1 for anyone whose computer was built in 2001).
For data file you can just use SignedData normally, for executables it's harder since there are semantic portions (so you have to squirrel it away somewhere and use indirect signing).
If you do your signing with .NET, PKCS#7/CMS SignedData is available for both signing and verifying via System.Security.Cryptography.Pkcs.SignedCms (though you probably have to define your own chain trust rules outside of that class).
Last summer, I was working on an application that tested the suitability of a prospective customer's computer for integrating our hardware. One of the notions suggested was to use the HTML report generated by the tool as justification for a refund in certain situations.
My immediate reaction was, "well we have to sign these reports to verify their authenticity." The solution I envisioned involved creating a signature for the report, then embedding it in a meta tag. Unfortunately, this scenario would require the application to sign the report, which means it would need a private key. Once the application is storing the private key, we're back at square one with no guarantee of authenticity.
My next idea was to phone home and have a server sign the report, but then the user needs an internet connection just to test hardware compatibility. Plus, the application would need to authenticate with the server, and an interested party could figure out what credentials it was using to do that.
So my question is this. Is there any way, outside of obfuscation, to verify that the application did indeed generate a given report?
As Eugene has rightly pointed that my initial answer was to authenticate the receiver. Let me propose an alternative approach for authenticating the sender
authenticate the sender:
When your application is deployed at your client end, you generate and deploy a self signed PFX certificate which holds the private key.
The details of your client and passphrase for the PFX is set by your client and may be you can get it printed and signed by your client in paper to hold them accountable for the keys which they have just generated..
Now you have a private key which can sign and when exporting the HTML report, you can export the certificate along with the report.
This is a low cost solution and is not as secure as having your private keys in a cryptotoken, as indicated by Eugene, in the previous post.
authenticate the receiver:
Have a RSA 2048 key pair at your receiving end. Export your public key to your senders.
When the sender has generated the report, let the report be encrypted by a symmetric key say AES 256. Let the symmetric key itself be encrypted/wrapped by your public key.
When you receive the encrypted report,use your private key to unwrap/decrypt the symmetric key and in turn decrypt the encrypted report with the symmetric key.
This way, you make sure that only the intended receiver alone can view the report.
I'd say that you need to re-evaluate possible risks and most likely you will find them to be not as important as you could think. The reason is that the report has value for you but less likely for a customer. So it's more or less a business task, not a programming one.
To answer your concrete question, there's no simple way to protect the private key used for signing from being stolen (if one really wants to). For more complex solutions employing a cryptotoken with private key stored inside would work, but cryptotoken is itself a hardware and in your scenario it would unnecessarily complicate the scheme.