Correct me if I am wrong, but if a byte of an app is changed then the signature of the app changes too. But in this library https://github.com/javiersantos/PiracyChecker in section verify signature there is written that we shoud save the signature in a variable and check if it is correct. I tried it and it works. But if we save signature inside a variable that means the app is changed which means the signatue is changed also and then it can't pass the check wright? So how is that possible?
how does a signature check works?
I now understand it. When a private key creates a certificate, then that certificate can be checked using the public key. But the piracy check included is using the public key or hash of the public key and NOT the whole apk digital signature. When any part of the app is changed there is a high probability that the app digital signature changes. On the other hand, using a public key or hash of a public key inside the piracy check enables us to sign the app using our private key. The piracy check verifies if the app is signed with the equal public key or hash of the public key that is stored inside the code.
Related
I want to aquire a token from an Azure app registration with a certificate.
I followed the instructions here and generated a self signed certificate with Powershell. I also imported the public key into the portal.
But if I want to access the app via .NET, I need to provide the following MSAL configuration:
The CertificateFileContents is just the public key I exported from the certgmgr. But what should I put as the CertificatePass? Is this a hash? Or a private key? I could not find anything in the docs and also the link above does not give me any advice...
Also I do not really understand why the private key is not imported to the portal?
In my experience, CertificatePass should be required when you export a private key.
This document has such content before:
Export the private key, specify a password for the cert file, and
export to a file.
But now it only tells you to export a public key. You can see details from this issue.
So based on the SharePoint document, if you are reading a PFX file from your local machine, I think you should use private key with a password.
Okay, the CertificatePass was the password for the certificate itself.
The Azure Portal itself only holds the public key.
The client application needs to provide the whole certificate with private and public key.
If you export a private/public key from certificate manager in Windows 10, you will not be able to directly export this as base64, but you can create a pfx file.
Those files can later be encoded to Base64 with a tool of your choice. For example this.
The password for your certificate has to be the CertificatePass, the FileContents are the Base64 public and private key, but decrypted with the password.
This is of course only an approach for testing purpose. In a production environment you would rather use key vault or something similar to not have any secrets in your appsettings.json.
I want to know the ability to perform the signature on a data record ( Workflow item for example) using certificates Stored in Active directory.
I guess the signing operation will be : get the certificate of a user from active directory and generate a signature to sign the Data with it. ==> "how to get a certificate of a certain user?!"
and I guess the verifying operation will be : compare the public key stored in the signature , with all public keys of certificates in active directory , till finding the matching one , to guarantee it is a verified signature
Is that true please ? do i miss the implementation of CRL check ? and trusting certificate in windows Trust Store? where to save public Keys?
I have created one efi and signed with pesign using the docs -
UEFI secure boot :
https://en.altlinux.org/UEFI_SecureBoot_mini-HOWTO
https://en.opensuse.org/openSUSE:UEFI_Secure_boot_using_qemu-kvm
https://en.opensuse.org/openSUSE:UEFI_Image_File_Sign_Tools
https://wiki.ubuntu.com/SecurityTeam/SecureBoot
http://tomsblog.gschwinds.net/2014/08/uefi-secure-boot-hands-on-experience/
And booted with :
sudo qemu-system-x86_64 -L . -pflash /usr/share/qemu/OVMF.fd -hda fat:uefi_disk
uefi disk contains signed efi file
But to secure boot I need to have
DB
DBX
KEK
PK
so that I can enroll in OVMF secure boot
But in the tutorials, never got these how to generate.
Please suggest
In addition to generating keys for secure boot, one need to take care of signing the keys.
procedure for generating keys, signing and storing them to keystore is defined in detail here https://www.rodsbooks.com/efi-bootloaders/secureboot.html
Security keys can be categorised in 2 ways Private and Public and secure boot follow chain of root of trust for key addition PK=>KEK=>DB. Any changes in DB needs to be signed using KEK private key, changes in KEK needs to be signed by PK private key and changes in PK requires key to be signed by previous PK publik key's private key.
Generate PK pair and sign PK public key with private key. PK is a self signed key.
Generate KEK pair and sign KEK public key using PK private key
Generate DB key pair and sign DB public key using KEK private key
Generate DBX key pair and sign DBX key pair using KEK private key
Note : for replacing previous PK from BIOS, you will require an empty key signed by platform owner. Most BIOSs allow changing keys without verifying but ideally it should not be allowed. Whole purpose of secure boot is that things can be traced to root of trust and verified.
Apart from generating completely new set of keys, you can also use Machine Owner's Key MOK for registering a new key with secure boot.
Generate a key pair
sign your utility using private key(using sbsign)
add public key to MOK utility (using mokutility)
also described in link mentioned above
How do I verify a user's extended public key file's integrity (when downloading through a connection that lacks confidentiality and authentication) when I have their previous (now expired) public key in my keyring? Is their expired key sufficient information to verify the extended key? Consider the below scenario:
I have Bob's trusted public key in my keyring.
Bob's key expired yesterday, so he extended his keypair and uploaded a new ascii-armoured public key to his website.
I downloaded Bob's new public key file over http, and I want to verify it.
Is the new public key file signed with his old key in a verifiable way? How would I verify the integrity of the new key file utilizing his existing (expired) key in my keyring?
For a general scenario with a new key pair: If either the key itself is signed by his old key (this is the usual way to do such key changes) and/or the key file you downloaded is signed by his old key, you can verify and validate the signature anyway: all that happens is GnuPG indicating that the key already expired.
But you wrote
Bob's key expired yesterday, so he extended his keypair and uploaded a new ascii-armoured public key to his website
Extending the key's validity does not produce a different key. They key is identified by the tuple of public key and creation timestamp, which is hashed together to the fingerprint of the key. Short and long key IDs are derived from that. If all he did is indeed extend the validity of the key, simply import the key. The signature and trust you issued on that key are still valid.
If you wish you can compare at least the long key ID before importing, run
gpg --keyid-format 0xlong [key-file]
and compare with the key already in your key chain.
Anyway: don't simply trust keys in your key chain, but use signatures and trust instead. Lots of mail clients automatically fetch keys to verify signatures, you might have fetched some (unvalidated) keys for reading signatures issued on other keys, ...
I'm asking this question in order for be 100% sure.
link
To validate the certificate to ensure it contains the information
digitally signed by the certificate authority, the web browser
verifies the digital signature. Because the digital signature is an
encrypted hash value that was computed based on the contents of the
certificate, the web browser needs to compare hash values. The web
browser computes a hash value based on the contents of the certificate
it received. It then decrypts the digital signature to determine the
hash value that the certificate authority computed. If the two hash
values match, the web browser is assured that the certificate contains
the information that the certificate authority verified and digitally
signed.
questions :
The web browser computes a hash value based on the contents of the
certificate it received
The browser knows in which digest algorithm the certificate was used inside , so he uses it also to calculate a hash - based on the certificate content.
It then decrypts the digital signature to determine the hash value
that the certificate authority computed
The browser knows which CA created the certificate , so he takes the public key from the appropriate computer store location and apply it on the encrypted hash value . the result is the decrypted hash value.
It then see if both the same.
Am I right ?
(You may be interested in this question on Security.SE.)
This is the structure of an X.509 certificate:
Certificate ::= SEQUENCE {
tbsCertificate TBSCertificate,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING }
TBSCertificate ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name,
validity Validity,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version MUST be v2 or v3
subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version MUST be v2 or v3
extensions [3] EXPLICIT Extensions OPTIONAL
-- If present, version MUST be v3
}
When presented with the certificate, the browser gets the signature algorithm from the certificate itself. Typically, this is something like RSAwithSHA1.
In this case, it can indeed recalculate the SHA-1 digest of the TBSCertificate (the actual content of the certificate).
In addition, from the TBSCertificate, it can find the issuer name: this is what's used to find a trust anchor from the known CA certificates (the issuer name must match the subject of the CA certificate). When it has found the CA certificate with the right name in the list it already trusts, it can get the public RSA key from that CA certificate.
Having both the SHA-1 digest and the RSA public key, it can verify that the signatureValue matches.
the digital signature is an encrypted hash value
That's not strictly true, although it's commonly said. Digital signatures are digital signatures, not encryption.
The problem is that RSA uses the same maths to encrypt and sign: encryption with the public key and signature with the private key. Often, one is confused with the other (even in the OpenSSL API). It doesn't make sense to "encrypt" with a private key, since "encrypting" implies hiding (and you're not hiding anything if you're giving the public key away so the it can "decrypt" the signature).
This subtly about hash and encryption with digital signatures wouldn't work with some other algorithms such as DSA, which are for signatures only.
This is why a number of digital signature APIs combine the hash and key usage into a single "sign" or "verify" operation. This is what the Java Signature API does, for example: you tell it to use RSAwithSHA1 or DSAwithSHA1, give it the key and the message, and tell it to sign or verify, you don't have to do the digest or "encryption" manually.
For the purpose of certificate verification: the browser gets the issuer from the cert and find the corresponding public key (from trusted CA certs), it also gets the signature algorithm from the cert, and then verifies the signature with that public key and the TBSCertificate content, according to what the signature algorithm dictates.