wultra/powerauth-crypto

PowerAuth - Open-source solution for authentication, secure data storage and transport security in mobile banking.

powerauth-crypto's Issues

WS SOAP- prepareActivation - getting always http response 500

I did write tests for SOAP WS PA 2.0, but I am just not able to get correct response even when trying to enter data manually with Wizdler

example:

2016-01-15 19:10:41.822 HawkNestModuleTest[43760:405270] OutputHeaders:
{
"Content-Length" = 948;
"Content-Type" = "text/xml; charset=utf-8";
Host = localhost;
SOAPAction = "";
"User-Agent" = wsdl2objc;
}

2016-01-15 19:10:41.823 HawkNestModuleTest[43760:405270] OutputBody:
<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:PowerAuthPortServiceSvc="http://getlime.io/security/powerauth" xsl:version="1.0">
  <soap:Body>
    <PowerAuthPortServiceSvc:PrepareActivationRequest>
      <PowerAuthPortServiceSvc:activationIdShort>Q3FN3-S6MBB</PowerAuthPortServiceSvc:activationIdShort>
      <PowerAuthPortServiceSvc:activationName>V</PowerAuthPortServiceSvc:activationName>
      <PowerAuthPortServiceSvc:activationNonce>ZoJy4IlgCw7H/bryw/AJNg==</PowerAuthPortServiceSvc:activationNonce>
      <PowerAuthPortServiceSvc:cDevicePublicKey>+FQ45WjMRH1ZA/YoGRkRhFYpUMcZmG+aB0ywYGWV0SMigS0cabxncJOuQ9hT9cwi</PowerAuthPortServiceSvc:cDevicePublicKey>
    </PowerAuthPortServiceSvc:PrepareActivationRequest>
  </soap:Body>
</soap:Envelope>

2016-01-15 19:10:41.852 HawkNestModuleTest[43760:405270] ResponseStatus: 500
2016-01-15 19:10:41.853 HawkNestModuleTest[43760:405270] ResponseHeaders:
{
Accept = "text/xml, text/html, image/gif, image/jpeg, ; q=.2, */; q=.2";
Connection = close;
"Content-Length" = 289;
"Content-Type" = "text/xml;charset=utf-8";
Date = "Fri, 15 Jan 2016 18:10:41 GMT";
SOAPAction = """";
Server = "Apache-Coyote/1.1";
}
2016-01-15 19:10:41.853 HawkNestModuleTest[43760:405270] ResponseBody:

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header/>
<SOAP-ENV:Body>
<SOAP-ENV:Fault>
<faultcode>SOAP-ENV:Server</faultcode>
<faultstring xml:lang="en">Unknown exception has occurred</faultstring>
</SOAP-ENV:Fault>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Enable building the server as JAR

Currently, PowerAuth server can be built only as WAR and deployed on container. It should be also compilable as JAR.

Usage in client-only applications (e.g. single page javascript app)

It would be nice if you can describe if and how PowerAuth can be used in applications without server side (e.g. single page javascript application), which can hardly store any confidential informations.

Typo in activation process

In activation process description, there is probably a typo in 12 (receiving & verifying server public key on client), e.g.

boolean isSignatureOK = ECDSA.verify(C_KEY_SERVER_PUBLIC, C_KEY_SERVER_PUBLIC_SIGNATURE, KEY_SERVER_MASTER_PRIVATE)

should probably read

boolean isSignatureOK = ECDSA.verify(C_KEY_SERVER_PUBLIC, C_KEY_SERVER_PUBLIC_SIGNATURE, KEY_SERVER_MASTER_PUBLIC)

Decompose the mobile API project

Currently, we have one project "mobile-banking-api-java" that should be separated into three projects:

• PowerAuth SOAP Client
• RESTful API model classes
• RESTful API Server

Rename C-prefixed attributes in transport object to encrypted-prefixed.

The C prefix causes issues in automatic object unmarshalling. See discussion under #33.

Check for (short) activation ID duplicity

It should not be possible to create two activations with the same activation ID or short activation ID (for short activation ID, it should not be possible to have two CREATED or OTP_USED activations with the same value).

Implement vault unlock mechanism

It is required to implement the /pa/vault/unlock endpoint as explained in API docs.

Change entity attribute type from byte[] to base64 string

Following fields:

private byte[] serverPrivateKey;
private byte[] serverPublicKey;
private byte[] devicePublicKey;

Should be fixed to Base64 strings, to improve readability for DB admins.

Allow custom per-activation expiration period

Currently, all activations have hardwired time window for an activation based on a default value. It should be possible to override the activation time window in code, so that different applications can have different time window.

Swapped key and message in HMAC calculations

In

public String computeSignature(byte[] data, List signatureKeys, int CTR)

you're using key instead of message (and vice versa) in some HMAC calculations. For example,

KEY_DERIVED_CURRENT = Mac.HMAC_SHA256(KEY_SIGNATURE, CTR);
SIGNATURE_LONG      = Mac.HMAC_SHA256(DATA, KEY_DERIVED);
KEY_DERIVED         = Mac.HMAC_SHA256(KEY_DERIVED, KEY_DERIVED_CURRENT);

// ...and definitions.md says:
Mac.hmacSha256(SharedKey key, byte[] message) ...

The calculation of SIGNATURE_LONG in the documentation doesn't make sense at all, but fortunately the reference java impl. is correct. I think that we should always use key as key and message as message.

Signature validation: Implement counter synchronization

Currently, only the current counter value is used when validating signature on server. This usually is not sufficient because client may be several iterations forward. Following must be implemented:

• In case the signature is not valid, try incremented counter (try about 50 iterations)
• In case signature is valid for some iteration, return that signature is valid and increment the counter

Implement "vault unlock" method in testing tool

Currently, the Java command line tool does not have a "unlock" method to check the vault unlocking.

As a result, this endpoint is not well tested.

Issues in documentation

Hello,
I'm sending you a several suggestions about the documentation, just to be clear and to prevent some possible misinterpretations:

• PBKDF2 should be more specified
  • Please add which pseudorandom function is used in the scheme (e.g. HMAC-SHA256, SHA1, etc...)
  • Please specify what's your notation for that function. Now the implementer don't know what's the salt, password, etc...
• Mysterious GET_BYTES function
  • ...is completely unclear. I didn't get it. Is it a conversion from already pure ASCII to "just to be sure UTF-8" or some conversion from BASE32 to binary data? Or some kind of type abstraction, like "now we're casting a string into a blob of binary data"?
  • GET_BYTES(ACTIVATION_ID_SHORT + "-" + ACTIVATION_OTP, "UTF-8") ... i guess that in this case it is converting B32 into bytes. So then, the function will have to deal with separator, which is not a valid character for B32 encoding. That's creepy. I understand that in some activation step we'll show that to the user and thus the visual separator is very appreciated, but this fact should not affect a way, how the information is transmitted over the network or via the QR code..
• Usage of AES
  • The block mode and padding scheme is not specified.
  • Instead of simple "AES" & "AES^inverse", you should use AES_encrypt / AES_decrypt, just to be more clear
  • The same as PBKDF2, it's unclear what's your notation (e.g. what's password, data, iv...)
• Usage of ECDSA
  • Similar to AES. It's better to use ECDSA_sign / ECDSA_verify naming instead of ECDSA / ECDSA^inverse
  • There's SHA256withECDSA signature used, but that's mentioned in the code examples only. Should be also in the pseudo-algorithm part of the documentation
• BASE64
  • BASE64Encode doesn't have "encoding" parameter, like UTF8. I think it's not necessary to highlight, that result is a string :)

Well, hope that's all. I think it will be enough to add some introduction notes, which will describe what's going on when, for example, PBKDF2 is used in the documentation. Something like "PBKDF2(salt, password, iterations) uses HMAC_SHA256 as pseudorandom function.", "AES_Encrypt(data, iv, key) means AES in OFB mode with PKCS7 padding", etc...

Refactor code to include PowerAuthClientKeyDerivation and PowerAuthServerKeyDerivation

Currently, we derive keys on way too many places: in key generator, in signature utilities, in vault utilities...

It would be better to have a single pair of (de facto utility) classes that derive all required keys in one place...

Use "dateTime" instead of "date" in XSD

Spring interprets "date" as Java Date object, with date and time. However, WSDL specification states "date" should be used only for dates and some frameworks (like Axis) follow this specification.

We have to replace "date" with "dateTime".

Consider renaming the default SOAP interface to something else than "powerauth"

Currently, the customer we have uses URL "http://xyz:1234/powerauth/powerauth" - the double "powerauth" endpoint seems a bit confusing...

WS - InitActivation -"Master server key pair contains private key in incorrect format" exception raised

While having data in DB/Table "powerauth.pa_master_keypair" with id "1" correctly stored (using the script enclosed with this project), the WS InitActivation returns "Master server key pair contains private key in incorrect format" exception where UserId = 1 is an input parameter.

Component scan in a sample application works by a side-effect

Both sample RESTful API and PowerAuth RESTful Security module use "io.getlime.rest" package.

As a result, component scan in a demo app just work while an actual implementations need to specify a component scan. It should be either fixed in code (figure out a way to scan components) or a documentation should be updated.

Change entity timestamp attribute from Long to Date

private Long timestampCreated;
private Long timestampLastUsed;

Prepare support for security on SOAP service

Currently, the service is not secured by any means. We should allow deployers to enable WS-Security.

http://stackoverflow.com/questions/13512883/how-to-use-encrypted-password-in-wss4j-spring-security
http://blog.krecan.net/2010/06/07/spring-ws-security-on-both-client-and-server/comment-page-1/

Prepare the Android module compilation

Besides writing a bit of a helper code, Android package should consist of:

• powerauth-java
• powerauth-java-prov-spongycastle
• powerauth-restful-model

Use "long" instead of "Long" in "powerauth-java"

Currently, we use Long way too often - we could replace it by long in all crypto part (networking and DB part should probably still be Long).

Handle HttpMessageNotReadableException in case of the i.e. empty body

Currently, when user POSTs empty body on any REST endpoint, the presented exception is not very nice from a readability perspective. It would be nicer to handle this in a better way.

Prepare abstraction to allow BouncyCastle / SpongyCastle switch

Currently, the "powerauth-java" module uses BouncyCastle for the cryptography. As a result, it cannot be used on Android platform.

We need to do following steps to change that:

• replace hardcoded "BC" with a variable, so that it can be easily replaced
• move "KeyConversionUtilities.java" (the only place with BC imports) to separate maven project ("powerauth-provider-bc")
• prepare "KeyConversionUtilities.java" with a SpongyCastle provider as a separate maven project ("powerauth-provider-sc")
• have "IKeyConversionUtilities" interface in "powerauth-java" and use it instead of the class
• rename "PowerAuthConstants.java" to "PowerAuthConfiguration.java", make it a singleton, and allow setting the IKeyConversionUtilities implementation there
• add dependency on BC version of KeyConversionUtilities in other projects
• fix the maven module documentaiton

@tomas-vondracek: Any comments or strong hate? ;-)

WS - GetActivationStatus returns CREATED for any non-existing Activation ID

Seems like using a new state, which could be introduced for the activation statuses enumeration sounds more correct then getting status CREATED for any input that is not present in DB/Table -> pa_activation.

CTR in statusBlob has different bit size than in calculations

The CTR returned in statusBlob is 32 bit value but every operation related to CTR uses 64 bit counter. I know that the CTR is just an informational value here and right now we don't have practical usage for it. But still I think that this should be adjusted and we may use one common type for the counter.

You'll probably need to extend the blob to two AES blocks to keep enough entropy.

Btw, if you gonna to accept this issue and extend the structure, you should use different "magic" value. The 0xDEADBEEF is so lame, because everybody is using it. What about 0xDEC0DEAD / 0xDECODEED or anything more funny (https://en.wikipedia.org/wiki/Hexspeak:)

...in fact, I created this issue just because that "magic" :) We've been already discussing this topic personally and I know that you'll extend the blob someday.

Implement high-level Android interface

Currently, the Android module is just a collection of maven dependencies. It should also contain some code for simpler implementation of PowerAuth 2.0 Client.

Fix project dependencies on database engines

Currently, we have the dependency on MySQL database. We should make this more decoupled...

Define KDF better in docs

Currently, the KDF definition is too hidden - it should be a part of definitions.

Change Long to Byte in MasterKeyPair entity class

There is forgotten attribute of "Long" type that should be date in Master Key Pair entity class.

Review the sequence diagram for PowerAuth activation

Currently, there is an activation flow sequence diagram available. It requires a deeper review before it can be declared final.

Refactor PowerAuthServiceImpl class

Currently, the class has over 1000 lines which is way too many. It would be nice to use the "behaviour pattern" for this one.

The default username for PowerAuth server should be "powerauth", not "root"

Using a "root" user does not simply feel right for any purpose than DB administration.

Client names server public key "clientPublicKey"

See:

https://github.com/lime-company/lime-security-powerauth/blob/master/powerauth-docs/source/tutorial/console-client-app.md

Restrict activation record validity

In case activation is in CREATED or OTP_USED states for more than N minutes (N is stored in a configuration), it cannot be used anymore for completing the activation.

Prepare official Oracle SQL scripts

Currently, we only have MySQL scripts. For one of the clients, we need to have Oracle...

Prepare testing vectors for cryptographic operations

Currently, all tests are performed "holistically" - we perform all activation steps in all systems, to prove the system as a whole works. However, it is a good practice to have testing vectors as well.

Consider deriving more signature keys and local storage key

Currently, master secret KEY_MASTER_SECRET is used to derive one signing key KEY_SIGNATURE and one transport key KEY_TRANSPORT. It would be nice to have:

• multiple signing keys (namely 3 - each for a single authentication factor)
  • KEY_SIGNING_F1
  • KEY_SIGNING_F2
  • KEY_SIGNING_F3
• one "local storage key" to encrypt the original private key so that it can be used for further key derivation or asymmetric ECDSA signature
  • KEY_ENCRYPTED_STORAGE

The sample PowerAuth RESTful API server does not map PowerAuth filter to requests

As a result, the request data (from body) are not forwarded to the authentication provider.

Mapping must be updated to be "/pa/signature/validate"...

Implement a full-featured reference PowerAuth 2.0 Client

Having a reference PowerAuth 2.0 client that works with the default SOAP interface and is able to call individual service requests is a must for an implementation verification.

More detailed specification of the API / interface TBD.

Evaluate if the resulting signature can be derived from 4 byte data

As with the HOTP standard, we use decimalized signatures constructed from 4 bytes, as seen here:

https://dl.dropboxusercontent.com/u/6405782/powerauth/index.html#computing-the-signature

While the declared signature length is 10 digits, 4 bytes have a very low entropy on the first digit. Namely, 2^32 = 4 294 967 296, plus we strip the negative numbers thus gaining only half of this number. Therefore, the first character of the signature can be only 0, 1 or 2...

We need to evaluate if this is a big issue, since signatures are always connected with given transaction and random nonces.

Possible solutions:

• allow use of non-decimalized long signature in HTTP request
• allow extending the signature length by not stripping 4 bytes only

[Maven] Remove "powerauth-java" dependency from "powerauth-restful-security"

Currently, "powerauth-restful-security" depends on "powerauth-java". The dependency there is actually more about "utility classes" than about actual crypto. Namely, following parts of the dependency are used:

• HTTP header / body utilities
• Guava by Google

Guava can be added directly, HTTP utilities should be moved to a separate maven project (for example "powerauth-java-http")...

Implement a full-featured reference Master Front-End Application

An example implementation of PowerAuth 2.0 Master Front-End Application is needed in order to assure testability of the project and in order to have a simple integration example.

Data turns out to be double Base64 encoded on the server, validation fails

Currently, when I try to validate data from data file, validation fails. Audit log shows that data seem to be double base64 encoded.

Add per activation max attempt count

Currently, the max attempts are fixed in PowerAuth configuration. It would be better to be able to set this number per activation, so that different apps can use different values and so that the check is more explicit...

Implement signature auditing

It is required to have a table where PowerAuth Server stores the log of attempted authentications.

Release Maven dependencies in the default JCenter repository

Currently, we distribute the libraries using the ZIP package. It would be better release them in the central Maven repository, so that they are accessible the typical Maven way.

ApplicationID and applicationSecret as a first-class citizen in PowerAuth server

Instead of adding applicationID and applicationSecret support in "client" webapp, we should add it in PowerAuth server, so that the configuration is simpler for an integrator. Also, each activation record should have a "pointer" (ID) to the application it was created for so that the secret can be retrieved. The main result will be that "secret" will be really shared just between PowerAuth Client and PowerAuth Server. As a minor benefit, "extras" field meaning will be also more explicitly grounded by the associated application.

Consider chaining multiple signature keys to get more powerful signature

Currently, we compute signature only from a single symmetric key KEY_SIGNATURE, therefore effectively gaining 1FA. Maybe it would be nice to define signature types and use them:

• SIGNATURE_TYPE_1FA_POSSESSION
• SIGNATURE_TYPE_1FA_KNOWLEDGE
• SIGNATURE_TYPE_1FA_BIOMETRY
• SIGNATURE_TYPE_2FA_POSSESSION_KNOWLEDGE
• SIGNATURE_TYPE_2FA_POSSESSION_BIOMETRY
• SIGNATURE_TYPE_3FA_POSSESSION_KNOWLEDGE_BIOMETRY

Signature type always says:

• How many factors are used
  • 1FA, 2FA, 3FA
• What is the order of evaluation for given factors, factors are evaluated additively, not exclusively, to assure proper M-FA authentication.
  • POSSESSION_KNOWLEDGE => "something I have" + "something I have and something I know"

Depends on issue #10.