Do HSM companies usually provide a PKCS#11 API to work with the HSM or do they just provide their own Cryptographic API?
In each case how to integrate to a Linux Application(using OpenSSL, possibly like how one would call an openssl engine for a 3rd party library?) and to a Windows Application?
What is generally preferred? PKCS#11 API or a generic API?
What are the advantages and disadvantages of the two?
A HSM vendor has told us that they can provide both a PKCS#11 API and a crypto API written in C language. I am trying to understand the terms and therefore this question!
A simple overview would me to research further :)
Many thanks!
Generally a PKCS#11 library is supplied, if just to compete with the other products that also supply such a library. PKCS#11 is a common interface that can be used from software. There are many software packages that allow the use of the PKCS#11 token standard underneath, such as the OpenSSL PKCS#11 engine and a PKCS#11 security provider in the Java language.
Although PKCS#11 can be extended this doesn't mean that all the functionality of a HSM can necessarily be supported. PKCS#11 is a relatively low level interface. Sometimes it makes more sense to use proprietary API's that better fit a specific use case. The more parts of a cryptographic protocol can be performed on a secured device, the better.
As for which one is better, that depends entirely on your use case and threat model as well as the crypto API that can be provided.
PKCS#11 (definition from wiki)
The PKCS #11 standard defines a platform-independent API to cryptographic tokens, such as hardware security modules (HSM) and smart cards, and names the API itself "Cryptoki" (from "cryptographic token interface" and pronounced as "crypto-key" - but "PKCS #11" is often used to refer to the API as well as the standard that defines it).
So this is generally the standard API all the HSM manufacturer's use.
It completely depends on the HSM vendor if they implement this API. If they did implement it, you should be able to communicate with their hardware using the standard PKCS#11 API from any platform (provided they support it) or any third-party libraries that can act as a middleware between your software and their hardware. If they didn't implement it, they usually write their own proprietary API that may be specific to a platform and communicate with their devices only. This forces you to use their API to communicate with their hardware (HSM in this case).
So, from your perspective, if you used the standard PKCS#11 API and in future if you collaborated with another HSM vendor, you can use your same code to communicate with the new HSM as well (because PKCS#11 is a standard). But if you used their own API, and to communicate with a new HSM vendor you cannot reuse your code, because their API might only work with their devices.
Related
I've recently come across the term api and from what I have known api is a interface that connects/integrates between two programs and it can run on any platform.
And again from java we know that it turns it's source code into bytecodes and this bytecode can run on any platforms since it is platform independent.
So my question is does api work/run just like as a bytecode to provide multi-platform functionality
And if not is there any similarities between them or thier process? If please anyone could explain it to me it would be a great help. Thanks in advance.
API does not work like bytecode
Actually, API and Bytecodes are a completely different thing
For Bytecode,
let's try to understand it in java. java compiler compiles a java program then produce bytecode. Then the bytecode is interpreted by java interpreter in different machines and generate different executable files as the requirement of different machines and os.
this is how java maintains it's multi-platform property
Now, API,
API stands for Application Programming Interface. An API is a software intermediary that allows two applications to talk to each other. In other words, an API is the messenger that delivers your request to the provider that you’re requesting it from and then delivers the response back to you.
there are many types of API's out there
but I think you are referring to Web API and it's multi-platform functionality and how it works.
A Web API is an application programming interface for either a web server or a web browser
A Web API works as server-client architecture.
client request to server through HTTP protocol, server responds to client through HTTP protocol
actually whole api service is provided through HTTP protocol, and this api service can provide to any device using HTTP protocol
this has nothing to do with bytecode
I have reading and developing my understanding with SOA, I found this approach of development useful. However there are couple of thing confusing me which are:
Background: we are designing online financial application, recently we are in phase of designing brain storming sessions. (audit & logging need to be done)
1 - how to make sure Secure inter process communication?
My thinking: to restrict external access to these API's by firewall. So these can only be call internally by system.
2 - what will be preferred protocol rest or soap in context of private api (IPC) and public APIs (exposed to clients for e.g mobile,web and desktop)
My Thinking: For read we can use Rest and for ACID compliance transactions we can utilize soap as its provide point to point security. Or for IPC we are thinking to utilize soap as its provide audit mechanism also.
3 - What is Role of API gateway? specially is it involve in inter process communication?
I am confused on this specially with IPC. I think all request even services to services call will perform via API gateway. Kindly elaborate this in detail if I am wrong.
4 - is this possible to keep some services public and some private in micro services architecture? how to logically separate both of them?
What ever I have research we can do this.
5 - What is major difference and pros and cons of SOA and Micro SOA?
My view: Msoa is extention of SOA.
Thanks in advance.
Can anyone draw a diagram or provide link of MSOA architecture diagram with API gateway.
APIGEE is primary source of my understanding, then google it specifics which move in different directions.
Security is our major concern.
1 - how to make sure Secure inter process communication?
Internally, whitelisting IP's and firewalls are probably the most secure. If these servcies scale and have dynamic IP's you may have an issue with that, in which case shared secrets can work, but ned to be put in place and respected across all services. JWT's are quite good for this (similar to SAML, but not as painful), used with an authentication microservice.
Externally - tokens, OAuth2 depending on how much pain you want to go through.
2 - what will be preferred protocol rest or soap in context of private api (IPC) and public APIs (exposed to clients for e.g mobile,web and desktop)
I would use REST, SOAP is slowly becoming an antiquated standard, you can secure comms p2p by using TLS or HMAC signing.
3 - What is Role of API gateway? specially is it involve in inter process communication?
An API gateway is usually used to expose legacy APIs to the public, or to manage a large set of internal services via single amanged interface. An API gateway can also help manage tokens for clients and offer a single token for multi-service access and obfuscate the internal APIs from the external interface.
Gateways tend to also offer developer portals and some kind of self-enrollment process as well as control flows for request content (inbound and outbound).
Tyk.io is an open source API Gateway - you can see the kind of features to expect from a gateway on their home page
4 - is this possible to keep some services public and some private in micro services architecture? how to logically separate both of them?
Yes, you can with an API gateway. So long as there are no inter-service dependencies.
5 - What is major difference and pros and cons of SOA and Micro SOA?
I think one is a subset of the other, SOA tends to be interconnected with a messaging structure like an ESB, but micro-SOA will bhe even more specialised and may not use an ESB.
The functions for operating the restful api is quite same. Is there any project that can generate the source code for different platform such android,ios and backend stuff.
I suggest you to use API description languages such Swagger ou RAML.
After having described your RESTful application with a language like this, you will be able to generate things like server skelekons and client sdks with different technologies and languages. You can even generate documentations.
With Swagger, swagger-codegen will do that. swagger-ui may also interest you for the documentation part.
To finish, I would like to mention the Restlet studio that allows to define graphically and quickly the structure of RESTful applications and generate then the corresponding Swagger and RAML contents. The APISpark plaform provides a mecanism to introspect Restlet applications and generate the corresponding contents with these languages. It also allow you to generate a set of server skelekons and client sdks.
Hope it helps you.
I will suggest you to use Spring RESTful webservices starter kit. Which will manage your back-end with centralized database. Also Spring has its own android libs to communicate with REST Apis.
I am looking for the methods in CommonCrypto to generate the shared secret based on ECDH. I can find proprietary implementations but nothing standard. This method is called sometimes Key Exchange and includes the calculation of the shared secret. Can someone send a link to the right documentation or to an example that uses CommonCrypto for generating the shared secret based on Elliptic curve Diffie–Hellman?
CommonCrypto implements ECDH. Apple Open Source includes the source code for the implementation. The problem is that the implementation is not exposed in the iOS SDK header files. I just checked iOS SDK versions 6.1 and 8.0, and the functions are not declared. This means that any app that somehow calls the routines will violate Apple's App Store Review Guidelines: Section 2.5 says "Apps that use non-public APIs will be rejected".
I suggest using OpenSSL, which includes ECDH.
There is a lot of stuff here on what an API is, but I can't find what I need on the distinction between plugin APIs and class library APIs. I don't get it anyway.
In the book, Documenting APIs, I read: The key difference between a plugin API and a class library API lies in the which party supplies the implementation for the exposed API.
Plugin API: The publisher creates an application and exposes a plugin API; the 3rd > party developer implements the API. The 3rd party developer plugin extends the functionality of the publisher's application.
Class library API: The publisher creates the API and implements it. The end-user uses the class library via its API to write an application. With a class library, the publisher implements a library of functionality that exposes an API.
I think I understand the plugin. I'm not clear on the class library API. Is it like a printer manufacturer creating a driver based on an O/S class library so that their printer works with that O/S?
If so, could you explain more about the differences in the APIs themselves? Are they both still a set of exposed methods? And how does the publisher implement its own API?
References
Documenting APIs: http://www.amazon.com/documenting-APIs-writing-developer-documentation/dp/0963002104
What is the difference between a Java API and a library?
Difference between framework vs Library vs IDE vs API vs SDK vs Toolkits?
API vs Toolkit vs Framework vs Library
They are both software interfaces. This means that they both look similar, typically a Java archive (JAR) containing a package (or multiple packages) with interfaces, classes, exceptions, etc.
I can understand why you found the explanation from the book confusing. As far as the API itself is concerned, the Java implementation is provided in both cases.
The major difference is in how this Java code is used. In the case of Plugin API (I like to call it Service Provider Interface, or SPI) you are primarily expected to add your own functionality by implementing the provided Java interfaces and/or extending the provided classes. On the other hand, you are only expected to call a Library API (I like to call it simply API), you are rarely expected to implement interfaces or extend classes.
Because of how they are used, there are many subtle differences between how you design an SPI and how you design an API. While I don't have a post dedicated to comparing SPI and API, when I discuss the various aspects of API design, I usually point out these differences:
http://theamiableapi.com/