I have two applications A1 and A2, both creating there own enclave E1 and E2.
A third application A3 is connected to A1 and A2. Is it possible for A3 to determine if the two enclaves E1 and E2 are actually running on the same system?
I don't agree with Surenthar's answer. If E1 and E2 are signed by the same Signing Identity MRSIGNER will always be the same for E1 and E2. Because MRSIGNER is a hash of that identity.
If A3 is also execute on the same platform it can simply spawn an enclave E3 and use local attestation which will only succeed for enclaves on the same platform.
If you have control over E1 and E2 then they could use local attestation to make sure both run on the same platform. Then A3 would have to use remote attestation to make sure it can trust E1's (or E2's) statement.
The Signing Identity provided by an authority, which signs the enclave prior to distribution. This value is called MRSIGNER and will be the same for all enclaves signed with the same authority. So in the same development firm all enclaves should have same MRSIGNER value, if they are signed with same Signing Identity.
This MRSIGNER values from two different enclaves in a development environment can be used to check whether two enclaves belongs to the same environment.
Related
I'm using electron-builder.
I can see their documentation mention about EV Code signing.
https://www.electron.build/code-signing.html#windows
But it doesn't say in detail HOW.
In docs, it says If you are using an EV Certificate, you need to provide win.certificateSubjectName in your electron-builder configuration.
But what about the CSC_LINK and CSC_KEY_PASSWORD env? Are they not needed?
Using EV cert, the certificate is bound to USB dongle and I can't export it as .pfx or set password.
So what should I do?
I'm answering myself.
You can omit CSC_LINK & CSC_KEY_PASSWORD since EV cert doesn't give you .pfx file and password.
Instead, you set certificateSubjectName in electron-builder's configuration.
Then it will automatically find certificate installed in your machine with that subject name.
When building, an authorization client used by your cert distributer will pop up to ask token password.
Of course, you need to have USB dongle plugged in.
In iOS, if pinned SSL certificate expires, do I need to re-submit the app? Will the apps with old version continue to work or will not work unless they are updated?
That entirely depends on how you pinned the certificate. Pinning a certificate means checking the certificate and its chain against a set of designated requirements that determine whether the new certificate should be accepted. There are nearly an infinite number of ways to do this, and thus nearly an infinite number of ways to shoot yourself in the foot while doing so.
As a rule:
If you are checking to see if the certificate's public key matches, you're fine as long as the new cert has the same public key. This is normally the simplest approach to get right, because you have the power to guarantee that a key under your direct control does not change. However, be aware that some automated certificate updating tools generate new keys by default.
If you are comparing the entire certificate, it will likely break, because obviously some aspects of the certificate (minimally, the expiration date) will change.
If you are comparing specific aspects of the certificate, such as the public key of the CA cert that signed it, it may or may not break, depending on whether those designated requirements match.
Be aware, however, that CAs periodically rotate out their signing keys to limit damage in the event of a key getting compromised. What this means is that the specific CA cert key that you pinned may not be the one that gets used to sign a subsequent certificate. And if you are doing this in an automated fashion, it isn't a question of whether you will break, but when.
For this reason, if you feel the need to do key pinning, it is strongly recommended that you pin only keys that are under your direct control, and that you force any automated update tools to reuse the existing key pair.
No. once you install ssl on your site or renew old one, it will start working. no need to resubmit the app.
read more at SSL Pinning and certificate expiry
I have an interesting problem. Let's say we have a user, Bob, who logs in to some service. How can that service prove Bob's identity, assuming Bob actively wants others to try and impersonate him? i.e. How can we be sure that the user logging in is indeed Bob?
Using the MAC/IP address of Bob wouldn't work as these can be easily spoofed.
A username/password as means of authentication wouldn't work since Bob could just give these credentials to anyone.
A public-key system (e.g. using RSA for signing) wouldn't work as Bob could just share his private key with anyone.
What I essentially need is Bob to have some proof of ID that he cannot share (or is at least hard for someone else to replicate, given all information that Bob has).
Edit (in case this is useful): I'm working with an iOS app (Bob) and a Python web server (the service).
Alternatives:
Hardware token that the user must present during authentication like a usb token or a cryptographic smartcard
Biometrics can not be shared. For example fingerprint/voice/ear/iris recognition. In some cases you will need a reader (note fingerprint biometric data is not available in mobile devices), and you have to work with confidence ranges and huge databases for comparison. An ID is never 100% reliable.
public key cryptographic systems that manage non-extractable keys. The cryptographic provider in user side allow to generate or import keys that can be marked as non extractable, and can not be exported outside. e.g WebCryptographyApi, AndroidKeyStore, iOS KeyChain or Window Keystore. During user registration, is generated a cryptographic key pair, public and private. The public is sent to server associated with user account, and private is stored securely. Authentication is done with a digital signature using the private key.
See FIDO UAF (Universal authentication Framework) and FIDO U2F(Universal second factor)
https://fidoalliance.org/about/what-is-fido/
About iOS KeyChain, it allows to mark a key as non extractable. See Apple Documentation
Important
If you do not set the CSSM_KEYATTR_EXTRACTABLE bit, you cannot extract the imported key from the keychain in any form, including in wrapped form.
Take a look also to Store and retrieve private key from Mac keychain programatically
Before I always had to give push notifications certificates (p12 files) to the server developer, so he could send push notifications to my applications.
But as far as I understand now it's possible to do without these certificates according to https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/APNsProviderAPI.html#//apple_ref/doc/uid/TP40008194-CH101-SW1
According to Apple:
A provider authentication token is a JSON object that you construct, whose header must include:
The encryption algorithm (alg) you use to encrypt the token
A 10-character key identifier (kid) key, obtained from your developer account
The claims payload of the token must include:
The issuer (iss) registered claim key, whose value is your 10-character Team ID, obtained from your developer account
The issued at (iat) registered claim key, whose value indicates the time at which the token was generated, in terms of the number of seconds since Epoch, in UTC
The question is where to take these kid, iss, iat values from the developer account?
Actually I've watched the video from WWDC https://www.youtube.com/watch?v=IDBCTvHrix8, it explained almost everything.
1) for kid you need to https://developer.apple.com -> Certificates, Identifiers & Profiles -> APNs Auth Key -> Press + button -> choose Apple Push Notification Authentication Key (Sandbox & Production) (it was added not so long ago) -> After you create it, you will see Key ID in this item (new item will appear in APNs Auth Key menu). This is your kid value
2) iss is your team ID, to take it you need to Certificates, Identifiers & Profiles -> Identifiers -> App IDs -> Press on any of your App IDs (if you don't have any, you need to create one for your application) -> you will see the details where you will see Prefix: 8jkjlj2k . This is your team ID and it will be the same for all your apps in your developer account.
3) iat : As far as I understand it's the time when server developer generated the token on his side, so you don't need to provide this value to the server developer
Is is possible to authorize users at a machine level. For example, only when using authorized computers (my personal laptop or other managers' pcs) can one get access to the admin page? Any other computers should either get a denial of access message or something else. Authorized computer may still provide their own admin username and password in case people could fake a machine's identity, maybe. I'm not a security expert though.
Correct me if I misunderstand, but you are asking to only allow visitors on specific machines to access your website?
Jumping right into a solution here. The first question is how do you know which machines are "manager's" machines? Do you have a list of their IP addresses? Do you have some other ID on them?
If you have their IP addresses, then IP Whitelist them, and block all other ip addresses.
If you do not have their IP address, then you are limited. There is no machine ID that can be accessed through a web browser, so you'll need to create your own ID by setting a long lived cookie and a registration process.
Since you already have a login process, this next part is fairly easy. You've used this solution before. When you sign in to google mail and click "remember me" and don't need to sign in the next time your computer restarts, google has basically marked (set a cookie) your machine as yours.
Now, if you want to get super fancy, enterprises have NAC setup. Every system is identified before being allowed to connect to the network. Certain systems are given more access than others. For example, at a software development company, engineers may be given access to a production network while sales staff is not. When they connect, sales staff are move to a restricted vlan after identifying who they are and who the machine belongs to. If that were the case for your company, then you would whitelist an entire subnet block.
Last point. Chase bank uses the machine cookie concept like so: The first time you login they ask your username and password. Then the send a code to your phone or some third-party channel. After you enter the code, the set a machine cookie (same old cookie). The next time you login, they ask for username and password, then look for the machine cookie. If the machine cookie is there, then they don't make you enter the code again.
You could make that your registration process, except you provide the manager with a code they can enter. I don't think you want to get much more complex than a static password to register the machine, but if you did, you can generate one time tokens following the spec in rfc 4226.
You can't restrict access to specific computing device (as there are many types of devices used and there's no universal thing to bind to) but depending on your application design you still can solve your problem. You need to bind not to computer, but to other hardware device which is not possible to duplicate.
One of such devices is a hardware cryptotoken or cryptocard with the certificate and a private key in it. The user plugs the device to USB or to card reader respectively, then he authenticates on the server using the certificate and private key stored on this device). Client-side authentication using certificates is a large but well-known topic so I don't discuss it here.
While it's possible to move the cryptographic device to another computer system, it's not possible to duplicate it or extract the private key from it. So you can (with certain high level of reliability) assume that there exists only one copy of the private key and it's stored on certain particular device.
Of course you would need to create another certificate for each device, but this is not a problem - the only purpose of these certificates is to be accepted by the server, so the server can issue new certificates when needed.