I am new in SGX,In DCAP attestation a SGX quote is generated which is going to be used by the client to make sure the code or request is executed inside SGX so my question are:
when attestations occurs, how the client car verify the quote?
where the SGX quote is saved? how client can access it?
Related
I couldn't find exact answer.
In similar topics, people say that without Private key you can't view HTTPS response, but I am surprised, why key needed at all? For example, when browser requests https://example.com, it can read view it's html output.
And I want the same in WireShark (one of my program reads response from https://example.com and want to view just that page's outputed HTML). However, I can't understand why Private key is needed with this simple task?
If you didn't need to know the private key, an attacker wouldn't need it either – then any HTTPS traffic including login information, credit card numbers, photos, etc could be read by anybody that is on the same network as you (somebody listening to wi-fi traffic), or anywhere between you and the server (ISPs). This would be a disaster.
HTTPS (or more specifically TLS) was created for this purpose – to be able to communicate with remote parties securely without having complete trust in every single node on the way to the remote party. It relies on public-key cryptography, which makes it so that it is easy to encrypt messages with the public key, but extremely difficult (or practically impossible) to reverse the encryption without knowing the private key.
A browser which communicates with a server via HTTPS creates a link based on keys exchanged securely. Only the server and the browser know these keys, and so only the server and the browser can send and receive messages to each other.
Wireshark, even if it is running on your computer, is not running as a part of your browser and hence does not know the keys that the server and the browser agreed on. So it is impossible for it to read the traffic.
It may be somewhat surprising to know that even if somebody (Wireshark) can read all the data your browser exchanges with a server, it will not know the keys that the browser and server agreed on.
Traditionally, secure encrypted communication between two parties required that they first exchange keys by some secure physical channel, such as paper key lists transported by a trusted courier. The Diffie–Hellman key exchange method allows two parties that have no prior knowledge of each other to jointly establish a shared secret key over an insecure channel. This key can then be used to encrypt subsequent communications using a symmetric key cipher.
Diffie-Hellman key exchange, Wikipedia
My team is working on common criteria validation of one of the clients' products written in Delphi for Windows. The application uses winhttp api for making HTTP requests. We are using tls-cc-tools for checking whether the application passes all the TLSC EXT1.1 assurance tests. We have been able to restrict the cipher suites and enable TLS 1.2 application wide and right now test 1, test 4, test 5.1, test 5.2 and 5.3 are passing but the remaining tests are not passing. The tests can be found over here.
We have set the following options in winhttp:
df:={WINHTTP_DISABLE_AUTHENTICATION or }WINHTTP_DISABLE_COOKIES or WINHTTP_DISABLE_KEEP_ALIVE or WINHTTP_DISABLE_REDIRECTS;
WinHTTPSetOption(iconnection, WINHTTP_OPTION_DISABLE_FEATURE,#df,sizeof(df));
protocols := $00000800; //WINHTTP_FLAG_SECURETLS1_2;
WinHttpSetOption(iconnection, WINHTTP_OPTION_SECURE_PROTOCOLS, #protocols, sizeof(protocols));
WinHTTPSetOption(iconnection, WINHTTP_OPTION_SECURITY_FLAGS,
#flags, sizeof(flags));
Tests that are failing:
Test 3: The evaluator shall send a server certificate in the TLS connection that the does not match the server-selected ciphersuite (for example, send a ECDSA certificate while using the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite or send a RSA certificate while using one of the ECDSA ciphersuites.) The evaluator shall verify that the TOE disconnects after receiving the server’s Certificate handshake message.
Test 4: The evaluator shall configure the server to select the TLS_NULL_WITH_NULL_NULL ciphersuite and verify that the client denies the connection.
Test 5.5: Modify a byte in the Server Finished handshake message, and verify that the client sends a fatal alert upon receipt and does not send any application data.
Tests 5.6: Send a garbled message from the Server after the Server has issued the ChangeCipherSpec message and verify that the client denies the connection.
What should be done to ensure that the remaining tests pass?
Preface: I’m a certified Common Criteria Evaluator and a software developer. I’ve been dealing with the TLS and X.509 test cases for years.
Some of these tests are incredibly non-trivial to do correctly under all circumstances, such as FCS_TLSC_EXT.1 Test 3 above. It would be impossible to diagnose why you aren’t seeing the effect without knowing much more about your implementation and (most importantly) test setup.
However, test 4 is quite straightforward: set up your TLS server to respond only with the NULL cipher regardless of what the client asks. That can be done by a man-in-the-middle or by hacking the server. Either should force the client to disconnect well before it gets along much further.
Tests 5.5 and 5.6 are pure man-in-the-middle tests. If you are already using the TLS-cc-tools, then the basis for the test is already there.
Check my profile for ways to reach out to me directly to get more help with CC and TLS and X.509 conformance. These test cases aren’t industry standard implementations and are only for those who are seeking CC certification. It’s a niche market.
I'm completely new to SSL and these ciphering stuff but I need to make communicate client and server Delphi XE6 apps running on mobile devices. The TCP communication has to be safely ciphered.
To start, I simply wrote the Delphi/Indy TIdTCPServer/TIdTCPClient based Win32 client and server exchanging strings. (Issued from the indy10clieservr demos found on SourceForge: svn://svn.code.sf.net/p/indy10clieservr/code/1_sample Simple String Exchange)
I tried to modify them to cipher the communication by adding a TIdServerIOHandlerSSLOpenSSL component on the Server, and a TIdSSLIOHandlerSocketOpenSSL on the Client, attaching them respectively to the TIdTCPServer and TIdTCPClient.
I set their following properties on both sides:
- SSLOptions.Method = sslvSSSv23
- SSLOptions.Mode = sslmServer / sslmClient (respectively)
- SSLOptions.VerifyDepth = 2
And I added an OnGetPassword Event handler setting the Password parameter to 'password' on both sides too.
(What is the role of this password ? Is it critical for the privacy of the communication ? What if it is found by analysing/reverse enginering the binary file ?)
Finaly, in the server's OnConnect event handler I set the TIdSSLIOHandlerSocketBase(AContext.Connection.IOHandler).PassThrough property to false.
But what about the 3 SSLOptions certificate properties ??
- CertFile
- KeyFile
- RootCertFile
How to generate and deploy them on my target devices to make run my SSL layer on the client and server ?
Moreover, is there something special to do or to take into acount if I intend to deploy later my server and/or clients on IOS or Android mobile device.
I'm aware that I have few knowledge on this SSL topic. Sorry if I ask something trivial. Any basic documentation explaining all of this tricky stuff to a newbie would be greatly appreciated.
As I told you in my answer to your same question on the Embarcadero forums, certificates are optional. They are used to allow peers to validate each other's identities, not for encryption. Certificates help avoid man-in-the-middle attacks, by allowing a client to verify it is connected to the correct server it is expecting to be connected to, and vice versa. It is not common for a client to have a certificate, except maybe when making a proprietary system where only authorized clients are allowed to connect. But it is pretty common for servers to have certificates, at least. Certificates can be password-protected, so if you do use them, you have to provide the correct password for the certificate(s) that you are actually using. A certificate's password can't be retrieved from the certificate itself, but if an attacker gains access to your certificate files then you have bigger issues to deal with.
As for SSLv23, it is a wildcard that allows dynamic version negotiation in cases where
client and server support different SSL/TLS versions. SSLv23 allows them
to figure out and use the highest version common to both parties. If a server
needs to support a wide range of clients, it makes sense to use SSLv23 on
the server side. Not so much on the client side. Since you control both
client and server, you should use use a specific version instead, preferrably
TLSv1 or higher.
I'm trying to obtain the supported cipher suite sent by the server during the the handshake protocol in an iOS app for HTTPS connections. So that, I could validate it against the recommended cipher suite in NIST Special Publication 800-52: Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations Table 3-2.
I tried looking into the class NSURLProtectionSpace's methods and other related entities like SecTrust, SecCertificate functions, and ran out of luck. I was unable to find anything in Apple doc titled as "Certificate, Key, and Trust Services Reference" too.
I found something interesting though. A 'C' function SSLGetSupportedCiphers. This needs a SSLSessionRef object as parameter. And then I wasn't able obtain SSLSessionRef object from NSProtectionSpace object as this is the only parameter provide by the delegate
"connection:willSendRequestForAuthenticationChallenge:".
And of course how should I be able to, as session is not yet established. (But I'm guessing that this class might have information about supported cipher suites as it represent the server realm).
Question: How to get cipher suite supported by the server, sent during the handshake protocol at client end, before sending credential to server.
Note: I can only use standard Apple API. OpenSSL is not available as option. :-(
My Delphi program has a built-in protection mechanism to check for banned license keys on the Internet and displays a message to the user if a blacklisted key is found.
I'd like to store the blacklisted key in the registry, so if the user tries to re-enter it (and he/she is not connected to the Internet), it's not accepted.
What is the best way to hide an obfuscated entry in the Windows registry?
Thanks!
Edit: You guys have some good answers there, but I feel like I need to expand the question.
This is not mainstream software but a corporate one. Clients pre-pay one year and get a one-year license key for activation. The license key includes a machine ID and can't be used elsewhere.
The problem is that some clients tend not to pay in time or they don't pay at all. Since I don't want to bother with shorter than one year license keys (too much administrative overhead) I need a way to disable their licenses till they pay.
So the app now will connect to the Internet upon launch and check if their key is blacklisted. If it is, I need to disable access. In case they reinstall or block Internet access, I need to know if the key has been blacklisted.
Thus, I'm thinking it would be best to hide it in the registry. My users are not tech-savy enough to use registry tools to monitor the registry, but if I put it under HKLM/Software/MyCompany/MyProgram, some of them might do find it. So I need a place where they can't find it afterwards that it had been created. (Noone will be expecting it!)
Any ideas?
The eaysiest way to hide a key or a value is to create a key/value having '\0' inside of the name. You can do this wth respect of the native functions NtCreateKey (see http://msdn.microsoft.com/en-us/library/ff556468.aspx) NtSetValueKey (see http://msdn.microsoft.com/en-us/library/ff557688.aspx) which use UNICODE_STRING as parameters instead of LPCTSTR. You can read more about usage of native registry API in http://www.codeproject.com/kb/system/NtRegistry.aspx for example. A Delphi code you will find here http://www.delphi3000.com/articles/article_3539.asp.
UPDATED: Because many people read this question I want to add some words to my answer. I want divide the part of the question which we can read also in the title "best place to hide a key in the Windows Registry" from the subject with license keys. Because I read some answers (written before me) which concerned almost only the part of license keys and read practically no answer on the question from the title I wrote me answer.
The subject with license key I find very complex. It depends on the licensing model choosed. It's important how to generate, to distribute (to install) and to verify the key. Is key should be hardware depended or not? It can be one per computer or one per computer group. The key generation, key installation or key verification can be either with respect of some online services (also from the internet) or without there. I can continue... There are a lot of aspects, advantages and disadvantages of different approaches.
So I decide to answer only on the main question from the title which is clear and have a separate interest. All other questions about license key should be discussed in my opinion in the separate question after clearing all requirements.
UPDATED 2 based on the updated question: It seems to me in your case would be better to use some scenario based on cryptographic signing of an activation ticket. For example the schema can looks like following:
You software installed on the client computer will need an activation. Before activation it can not work or work in very restricted form (for example only some menus needed for software activation are enabled).
You write a server component which will be used by client during the activation to generate the license key based of the activation request received from the client.
If a client pay for the software you include the information about the client's "machine ID" (in any form which you want) in the database on the server.
After starting of the activation process from the client software (either at the program start of from menu or in any other way like you want) it collects some information about the computer like computer name ("machine ID"), some serial numbers or some other information about hardware or operation system which can not be changed without a new activation. This information the software send to your server (it is the activation request).
The server verify that the the client with the "machine ID" payed for the software and is not yet activated. Then the server calculate the hash (SHA1, MD5 or some other) from the information send from the client and sign the respond with the server's private key (or servers certificate). The signed ticket server will be send back to the client. This ticket will play the role of licence key.
The server can add any additional information to the ticket before signing. For example it can add the information about the date till one the software should be valid (for example, current day plus one year). So the ticket which will be send back to the client can contain the hash of input activation information and any additional information, all what you want. Important is only that the information should be signed. In general you can include full client's request as clear text in the servers ticket instead of including of the hash, but the usage of the hash a) reduce the ticket size and b) makes the ticket a little more secure.
Every client have public key corresponds to the private key used by server for signing of the activation ticket. The client save the ticket received from the server during activation in any place in registry of in the file system.
Every next time if the client software will be started the software will read the saved activation ticket from the registry (or from the file system). Then the software collect the same information, which are used for generation of the activation ticket, calculate the hash and compare it with the hash from the saved ticket. It verify of cause the signature of the ticket with respect of the public key (or with respect of the server's certificate). Moreover the software can verify any other additional policy information from the ticket like the time till one the ticket is valid.
All written is a roughly schema only, but it is very simple and it is extensible. You need only study how use some simple cryptographic operation and implement there in your software.
As a option you can don't have a server online, but instead of that implement in the software (in menu for example) a possibility to generate the activation request and send it per email for example. Then you can offline (!!!) generate an activation ticket based of the server request and send the ticket back to the client also per email. A simple Reg-file which can be imported by double-click or some other simple import possibility in your software (cut & paste in the activation dialog) can end the process of the software activation.
I don't think that the registry is a good place to hide such info, because anyone can download and use the Process Monitor (http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx) tool and see what your program does with the registry.
And thinking about this again. You will probably make users of your software unhappy if it will leave things in registry and other "secret" places on the user's hard drive. Locations like that are also easily discovered by tools that monitor what system functions your software calls.
As an alternative you could embed the banned keys in your application when you release new versions. This way the banned keys will be hidden in the application making it much harder for crackers to bypass the protection.
The downside of this is that a user can potentially run older version with a banned key with internet access blocked to your site, but if your software is actively developed with new features and bugfixes added, then nobody would want to run older versions. And if you are very paranoid you could release "updates" which update just the embedded banned key list.
But in the end no software protection scheme is perfect. If your software is popular enough there will always be a pirate cracker who will figure out your protection and make a patch or even a key generator.
If you really want to go that way, hash or encrypt the keys and then check the hashed or encrypted user key to those on the registry.
Be sure to check if there's any keys in the registry to be sure if the user didn't erased them.
It will be very challenging to achieve what you're trying to do, since a user can simply uninstall and re-install, and savvy users can wipe all traces of your app from the system (including the registry).
Other apps (like Windows, for example), instead of checking for a negative (banned key), instead check for a positive (good key). You "activate" the software once (when connected online) and this activation stores the "good key", which you can then check for whenever running the software (whether online or offline).
I'd suggest the second approach for you.
Note that there are ordinary end-consumer tools that monitor what applications write to the registry (like Cleansweep). This goes on API call level, so it will probably catch #0 workarounds too.
You could try to encrypt the whole shebang in a registry key, with something that uniquely identifies the machine (like a mac address) and a timestamp, to avoid that people can move the key to other machines. THen always require the presence of such key to startup, and demand to connect to internet for updates/activation if it is not there. (or the timestamp is very old)