I'm not very expert in this kind of programming, and I know there is several similar questions, but anyone answered exactly that I need.
My team (and I) are developing a Public Key Infrastructure. We are stuck in the key generation (on client side), but we found so few documentation about it.
We know there are these options:
keygen tag --> generates a SPKAC request --> works in Mozilla to internal keystore, token and smartcard
crypto.generateCRMFRequest() --> generates a CRMF Request --> works in Mozilla to internal keystore, token and smartcard
CryptoAPI, CAPI, XEnroll CEnroll --> generates a CSR PKCS#10 (I think so) --> Works in Internet Explorer (we still haven't found code's examples)
Javascript or java Applet (yes I know, both are different) generates in all with sunpkcs11, bouncycastle or iaik API (can't reach any goal)
We found this options. but we don't know how to get the results, how to create to a CSR PKCS#10 request and how to handle it.
please, could you give me an advice about select the strategy, find how to implement and handle results, convert results and so? we are getting crazy!
Example: we know how to use the keygen tag, but we don't know how to set the key to only RSA 2048, and how to handle the SPKAC request to convert in a good CSR signed on SHA256
We tried to develop a Java Applet with iaik API, but the CSR generated had an error.
You are correct on all counts, as far as using browser tags to generate the keypair and/or certificate request. I recommend you take a look at the Odyssi CS project on Sourceforge. It's a very simple CA implementation written in Java/JSP. Take a look at the JSP files and you can see how the various options are being passed to the key generation tags.
Basically, you generate the keypair as part of a form submission. From there, they're available in the same way as any other request parameter. You'll need to know how to decode them on the backend. IE generates the request as a PKCS#10, which is nice since it's a well-documented standard. The SPKAC format isn't as widely used, but there are still good documentation and libraries available.
http://sourceforge.net/projects/odyssipki/
As Daniel pointed out, SPKAC is not broadly supported (even by CAs), it would be better if viable for your case to use PKCS10 in all browsers.
Here is an example doing that - https://github.com/PeculiarVentures/csrhelp
Related
I've created and signed a new executable file (the file is signed with double signature SHA1 and SHA256 and timestamped).
Since 1/1/2016 if I try to download it from Internet Explorer (or Microsoft Edge) I get an error (saying the signature is corrupted).
Smartscreen also tells that the file is not signed.
If I look at the file from the properties, it has the two signatures.
Can you help me out understanding what's the problem?
Here's the link for the download PhraseExpander setup file
Thanks.
This is what I wrote here:
valid certificate is corrupt with IE
I still doesn't have a solution, because I am not able to request a SHA-2 certificate. But you can't download any application from web with a SHA-1 certificate, anymore.
Class 3 certificates are a step above the Class 2. Class 2 does not require “Extended Validation”. However the “EV” code signing certificates combine all of the regular benefits of digitally-signed code with a rigorous extended validation process. They represent the gold standard for authentication and security in code signing certificates. EV code signing certificates adhere to strict validation standards from the CA/Browser Forum and to Microsoft specifications. Enhanced authentication is provided via an encrypted token containing the private key.
I'm developing an application using Chrome Native Messaging that starts through a Chrome Extension.
My question is: How can I ensure that host application is really the same supplied by me?
I need to ensure the authenticity the application called by extension. How do I get it if I don´t have permission to read registry or check if something was changed?
That is an excellent question, and my guess is the answer is "unfortunately, you can't".
It would be interesting to implement some sort of cryptographic hash like the ones Chrome uses to verify extension files, but that's not a very strong guarantee.
Consider (all of this hypothetical):
You can secure the registry entry / manifest pretty easily this way, but what about the file itself?
Suppose you pin a hash of the executable, then it becomes painful to update it (you'll have to update the extension too in sync). Can be resolved with some kind of public key signature though instead of a hash.
Suppose you pin the executable in the manifest. What about its data files? More importantly, what about the libraries a native app uses?
Securing a Chrome extension/app is easy, since the only "library"/runtime you rely on is Chrome itself (and you put trust into that). A native app can depend on many, many things on the system (like the already mentioned libraries), how do you keep track?
Anyway, this seems like an interesting thing to brainstorm. Take a look the Chrome bug tracker if there is already anything similar, if not - try to raise a feature request. Maybe try some Chromium-related mailing list to ask the devs.
I realize this is an older post, but I thought it would be worth sharing the Chromium team's official response from the bug I filed: https://bugs.chromium.org/p/chromium/issues/detail?id=514936
An attacker who can modify registry or the FS on the user's machine can also modify the chrome binary, and so any type of validation implemented in chrome can be disabled by such attacker by mangling with the chrome's code. For that reason chrome has to trust FS (and anything that comes from local machine).
If i understood the question correctly,The solution could be
Register your executable with your server while installing along with signing the executable and store your register number inside the executable and server
In Each Request (postMessage) from extension ,send a token in addition which was given by your server
Ask the server for the Next token to send response to the extension by passing the token from extension along with you registry number
Server will respond with the token if you are a registered user
Encrypt it with your registry number and send it to extension along with the token from extension
extension holder browser will ask the server its a good response
With the help of extension token the server will identify the executable registry number and decrypt the executable token and verify which was generated by us(server) for the extension token
Once server confirmed ,Browser will consider it as a response
To be important your registry number should be secure and the client machine cannot able to get it out from the executable(Using proper signing it can be achievable)
As chrome stopped support for Applet ,I implemented the same for smart card reader in chrome
The only loop hole is,The client machine can able to trace each and every request its sending with the help of some tools
If you are able to make your executable communication with your server be secure using some httpOnly Cookie(Client machine cannot able to read) or else the password mechanism ,Most probably a secure solution you can achieve
Client will send me data in the form of XML and JSON and I need to built service which store this data into database.For security purpose we want to get in the form of encryption and our backend is in java script we want to decrypt it in JavaScript. Client request can come either from PHP, Java, C# etc. Do you know any standard algorithm which has implementation in all popular languages and we can use for this project. We already implementation of DES algorithm in our system. If will be fine if there will be implementation of this algorithm in all other languages. If any one of you please let me know.
Thanks in advance
Why not use an https link? This will transparently encrypt the complete session and is available on all platforms.
So I came across this new tag in HTML5, <keygen>. I can't quite figure out what it is for, how it is applied, and how it might affect browser behavior.
I understand that this tag is for form encryption, but what is the difference between <keygen> and having a SSL certificate for your domain. Also, what is the challenge attribute?
I'm not planning on using it as it is far from implemented in an acceptable range of browsers, but I am curious as to what EXACTLY this tag does. All I can find is vague cookie-cutter documentation with no real examples of usage.
Edit:
I have found a VERY informative document, here. This runs through both client-side and server-side implementation of the keygen tag.
I am still curious as to what the benefit of this over a domain SSL certificate would be.
SSL is about "server identification" or "server AND client authentication (mutual authentication)".
In most cases only the server presents its server-certificate during the SSL handshake so that you could make sure that this really is the server you expect to connect to. In some cases the server also wants to verify that you really are the person you pretend to be. For this you need a client-certificate.
The <keygen> tag generates a public/private key pair and then creates a certificate request. This certificate request will be sent to a Certificate Authority (CA). The CA creates a certificate and sends it back to the browser. Now you are able to use this certificate for user authentication.
You're missing some history. keygen was first supported by Netscape when it was still a relevant browser. IE, OTOH, supported the same use cases through its ActiveX APIs. Opera and WebKit (or even KHTML), unwilling to reverse-engineer the entire Win32 API, reverse-engineered keygen instead.
It was specified in Web Forms 2.0 (which has now been merged into the HTML specification), in order to improve interoperability between the browsers that implemented it.
Since then, the IE team has reiterated their refusal to implement keygen, and the specification (in order to avoid turning into dry science fiction) has been changed to not require an actual implementation:
Note: This specification does not
specify what key types user agents are
to support — it is possible for a user
agent to not support any key types at
all.
In short, this is not a new element, and unless you can ignore IE, it's probably not what you want.
If you're looking for "exactly" then I'd recommend reading the RFC.
The keygen element is for creating a key for authentication of the user while SSL is concerned about privacy of communication and the authentication of the server. Quoting from the RFC:
This specification does not specify how the private key generated is to be used. It is expected that after receiving the SignedPublicKeyAndChallenge (SPKAC) structure, the server will generate a client certificate and offer it back to the user for download; this certificate, once downloaded and stored in the key store along with the private key, can then be used to authenticate to services that use TLS and certificate authentication.
Deprecated
This feature has been removed from the Web standards. Though some
browsers may still support it, it is in the process of being dropped.
Avoid using it and update existing code if possible. Be aware that
this feature may cease to work at any time.
Source
The doc is useful to elaborate on what is the keygen element. Its requirement arises in WebID that maybe understood to be part of Semantic Web of Linked Data as seen at https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index-respec.html#creating-a-certificate 2.1.1
This might be useful for websites that provide services, where people need to pay for the service, like video on demand, or news website for professionals like Bloomberg. With this keys people can only watch the content in their computer and not in simultaneous computers! You decide how data is stored and processed. you can specify a .asp or .php file that will receive the variables and your file will store that key in the user profile. This way your users will not be able to log in from a different computer if you want. You may force them to check their email to authorize that new computer, just like steam does. Basically it allows to individualize service access, if your licensing model is per machine, like Operating System.
You can check the specs here:
http://www.w3.org/TR/html-markup/keygen.html
I've done a little googling but have been a bit overwhelmed by the amount of information. Until now, I've been considering asking for a valid md5 hash for every API call but I realized that it wouldn't be a difficult task to hijack such a system. Would you guys be kind enough to provide me with a few links that might help me in my search? Thanks.
First, consider OAuth. It's somewhat of a standard for web-based APIs nowadays.
Second, some other potential resources -
A couple of decent blog entries:
http://blog.sonoasystems.com/detail/dont_roll_your_own_api_security_recommendations1/
http://blog.sonoasystems.com/detail/more_api_security_choices_oauth_ssl_saml_and_rolling_your_own/
A previous question:
Good approach for a web API token scheme?
I'd like to add some clarifying information to this question. The "use OAuth" answer is correct, but also loaded (given the spec is quite long and people who aren't familiar with it typically want to kill themselves after seeing it).
I wrote up a story-style tutorial on how to go from no security to HMAC-based security when designing a secure REST API here:
http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/
This ends up being basically what is known as "2-legged OAuth"; because OAuth was originally intended to verifying client applications, the flow is 3-parts involving the authenticating service, the user staring at the screen and the service that wants to use the client's credentials.
2-legged OAuth (and what I outline in depth in that article) is intended for service APIs to authenticate between each other. For example, this is the approach Amazon Web Services uses for all their API calls.
The gist is that with any request over HTTP you have to consider the attack vector where some malicious man-in-the-middle is recording and replaying or changing your requests.
For example, you issue a POST to /user/create with name 'bob', well the man-in-the-middle can issue a POST to /user/delete with name 'bob' just to be nasty.
The client and server need some way to trust each other and the only way that can happen is via public/private keys.
You can't just pass the public/private keys back and forth NOR can you simply provide a unique token signed with the private key (which is typically what most people do and think that makes them safe), while that will identify the original request coming from the real client, it still leaves the arguments to the comment open to change.
For example, if I send:
/chargeCC?user=bob&amt=100.00&key=kjDSLKjdasdmiUDSkjh
where the key is my public key signed by my private key only a man-in-the-middle can intercept this call, and re-submit it to the server with an "amt" value of "10000.00" instead.
The key is that you have to include ALL the parameters you send in the hash calculation, so when the server gets it, it re-vets all the values by recalculating the same hash on its side.
REMINDER: Only the client and server know the private key.
This style of verification is called an "HMAC"; it is a checksum verifying the contents of the request.
Because hash generation is SO touchy and must be done EXACTLY the same on both the client and server in order to get the same hash, there are super-strict rules on exactly how all the values should be combined.
For example, these two lines provides VERY different hashes when you try and sign them with SHA-1:
/chargeCC&user=bob&amt=100
/chargeCC&amt=100&user=bob
A lot of the OAuth spec is spent describing that exact method of combination in excruciating detail, using terminology like "natural byte ordering" and other non-human-readable garbage.
It is important though, because if you get that combination of values wrong, the client and server cannot correctly vet each other's requests.
You also can't take shortcuts and just concatonate everything into a huge String, Amazon tried this with AWS Signature Version 1 and it turned out wrong.
I hope all of that helps, feel free to ask questions if you are stuck.