I am working on a Master Card transaction processing app but still in the development stages. To be able to test my cryptogram validation app, I personalized a card using MChip with the following profile info:
MChip Jcop
app version 1.0
profile revision 1.0.11
requires universal OS.
After reading the contributions on these questions, Unable to Generate correct application Cryptogram and Generating Cryptogram Manually, I tried to check for my card's cryptogram version number but tag 0x9F10 was absent on my personalization data and there was no way I could add this tag before personalization. I have tried various cryptogram generation combinations on the Thales HSM but non is returning the same value as that returned by the card.
Being in the development stage with access to the development keys, I have checked to ensure the keys are good, same data passed for the cryptogram generation and at this stage I am completely clueless about what to do. I will appreciate any help I can get on this issue. Thanks
foreach (var tagLen in EMVTag.ParseDOL(crmDolstr))
{
requestData.Append(EMVData[tagLen.Split(',')[0]]);
dolData.AppendFormat("{0}|{1},", tagLen.Split(',')[0],
EMVData[tagLen.Split(',')[0]]);
}
string commandStr = string.Format("80 AE 8000 {0} {1} 00",
GetHexLen(requestData.ToString()), requestData.ToString());
byte[] hexData = Helpers.HexStringToBytes(commandStr);
apdu = new APDUCommand(hexData);
public APDUCommand(byte[] apdu)
{
if (apdu.Length < 5)
throw new Exception("Wrong APDU length.");
this.cla = apdu[OFFSET_CLA];
this.ins = apdu[OFFSET_INS];
this.p1 = apdu[OFFSET_P1];
this.p2 = apdu[OFFSET_P2];
this.lc = apdu[OFFSET_LC];
if (this.lc == apdu.Length - 5)
this.le = (byte) 0;
else if (this.lc == apdu.Length - 5 - 1)
this.le = apdu[apdu.Length - 1];
else
throw new Exception("Wrong LC value.");
this.data = new byte[this.lc];
System.Array.Copy(apdu, OFFSET_CDATA, this.data, 0,
this.data.Length);
}
The data you use (from CDOL) are not sufficient to generate cryptogram. Cryptogram usually includes AIP, ATC and CVR.
Please look at the response to the cryptogram generation for IAD as it usually contains also a dynamically generated CVR that is used in the cryptogram generation process.
Related
I have done some test using setStoreByValue(true/false) and I do not appreciate the difference.
I expect to store in the cache a lot of more that 30 objects when I use store by reference.
CacheManager manager = Caching.getCachingProvider().getCacheManager();
MutableConfiguration<String, CaLpgDataCollectionDto<CaBigNumber>> configuration = new MutableConfiguration<String, CaLpgDataCollectionDto<CaBigNumber>>();
configuration.setStoreByValue(false);
Cache<String, CaLpgDataCollectionDto<CaBigNumber>> testCache = manager.createCache("testCache", configuration);
//ICache is a Hazelcast interface that extends JCache, provides more functionality
ICache<String, CaLpgDataCollectionDto<CaBigNumber>> icache = testCache.unwrap(ICache.class);
List<CaLpgDataRowDto<CaBigNumber>> bigList = lpgDatasource.getDataRows();
while (bigList.size() <= 5000000)
{
bigList.addAll(bigList);
}
lpgDatasource.setDataRows(bigList);
System.out.println("Free memory before (bytes): " + Runtime.getRuntime().freeMemory());
for (int i = 0; i < 30 ; i++)
{
icache.put("objectTest"+i, lpgDatasource);
}
Am I using properly this propertie?
Kind regards.
JSR107 standard specifies that store-by-reference is an optional feature (see page 9 of JSR107 1.1.1 specification here. You can query a CachingProvider to test whether an optional feature is supported via CachingProvider#isSupported(OptionalFeature).
Hazelcast, being primarily used as a distributed cache, does not support store by reference. Keys and values have to be serializable in order to be transferred across the network among Hazelcast members and clients. Also, depending on the chosen in-memory storage format, values can be stored as serialized blobs (the default option with BINARY in-memory format) or as deserialized objects, however even in the latter case the value is serialized/deserialized first so it is a clone of the original.
My problem looks like this. I have generated keys on the card and the terminal sides. I have on the terminal side the card public and private keys and the terminals public and private keys, and the same on the card side (i'm doing tests so thats why i have all of them on the terminal and on the card). When i generate KeyAgreement (terminal side) for the card as private and for the terminal as private the secters are the same, so the generation is OK and i get a 24 bytes (192 bit) secret. When i generate the the secrets on the card (2 cases like on the terminal) the secrets are also the same, but they ale shorter - 20 bytes (160 bit). Here are the generation codes. the terminal:
ECPublicKey publicKey;
ECPrivateKey privateKey;
...
KeyAgreement aKeyAgree = KeyAgreement.getInstance("ECDH", "BC");
aKeyAgree.init(privateKey);
aKeyAgree.doPhase(publicKey, true);
byte[] aSecret = aKeyAgree.generateSecret();
and the card side:
eyAgreement = KeyAgreement.getInstance(KeyAgreement.ALG_EC_SVDP_DH, false);
short length = terminalEcPublicKey.getW(array, (short) 0);
keyAgreement.init(cardEcPrivateKey);
short secretlength = keyAgreement.generateSecret(array, (short)0, length, buffer, (short)0);
There is a problem in your implementation of KeyAgreement.ALG_EC_SVDP_DH in the terminal side. The correct length of output of the this method of key agreement should always be 20 bytes since SHA-1 is being performed on the derived output.
So in your terminal side, you should perform SHA-1 after generating the secret data.
all!
I'm solving two problems:
Stop using CAPICOM to sign/verify documents - because it's no longer supported by Microsoft (see more: Alternatives to Using CAPICOM)
Flowing out first we want to wide list of supported browsers by our system (customized Documentum webtop). Now it fully supported only by IE 6+ because of CAPICOM used as ActiveX.
For signing we use windows module CryptoPro because of only it officially have legal effect in Russia. Our system deployed in government of one Russian region.
Our system works already 5 years and there are many generated signs (all by CAPICOM). Signs is detached and persist in database.
We want to find solution to verify those signs in java code (wrapped in Applet).
I have tried code below, but I can't find any suitable method to verify any signature. This method always returns false.
public boolean verifyFile(String fileInput, String metadata, String base64Signature) throws Exception {
Security.addProvider(new BouncyCastleProvider());
byte[] signedContent = Base64.decode(base64Signature.getBytes("UTF-8"));
CMSSignedData cms7 = new CMSSignedData(signedContent);
CertStore certs = cms7.getCertificatesAndCRLs("Collection", "BC");
SignerInformationStore signers = cms7.getSignerInfos();
Collection c = signers.getSigners();
SignerInformation signer = (SignerInformation)c.iterator().next();
Collection certCollection = certs.getCertificates(signer.getSID());
Iterator certIt = certCollection.iterator();
X509Certificate cert = (X509Certificate)certIt.next();
Signature signature = Signature.getInstance("SHA1withRSA", "BC");
signature.initVerify(cert.getPublicKey());
String signedContentString = getSignedDataString(fileInput, metadata);
signature.update(signedContentString.getBytes("UTF-8"));
return signature.verify(signer.getSignature());
}
Have somebody any solution or already encountered this pr
I am implementing IQueryCancelAutoPlay COM interface and registering it with the Running Objects Table from a Windows Service*.
My problem is that it never gets called when I insert a mass storage device (or any device really). Here's some more information:
My code for registering with the ROT:
Text::string clsIdString = Text::to_string(Com::CLSID_QCAListener);
// remove curly braces
clsIdString = clsIdString.substr(1, clsIdString.length() - 2);
// set registry key to make sure we get notifications from windows
Reg::SetValue(HKEY_LOCAL_MACHINE,
_T("SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Explorer\\AutoplayHandlers\\CancelAutoplay\\CLSID"),
clsIdString, _T(""));
HRESULT result = S_OK;
// create class moniker ...
CComPtr<IMoniker> moniker;
result = CreateClassMoniker(Com::CLSID_QCAListener, &moniker);
if( !ValidateResult(result, "Error creating class moniker") )
return;
DBG << _T("Getting IRunningObjectTable pointer ...") << std::endl;
// get running oject table ...
CComPtr<IRunningObjectTable> runningObjectTable;
result = GetRunningObjectTable(0, &runningObjectTable);
if( !ValidateResult(result, "Error getting running object table") )
return;
// create an instance of the QCAListener class ...
Com::QCAListener * listenerInstance = new Com::QCAListener();
if(!ValidateResult( listenerInstance != 0,
"Error creating QueryCancelAutoplayListener"))
return;
// ... and set the pointer in the _qcaListener variable
CComPtr<IQueryCancelAutoPlay> qcaListener;
listenerInstance->QueryInterface(IID_IQueryCancelAutoPlay, reinterpret_cast<void**>(&qcaListener));
DBG << _T("Registering IQueryCancelAutoPlay with ROT ...") << std::endl;
result = runningObjectTable->Register(
ROTFLAGS_REGISTRATIONKEEPSALIVE,
listenerInstance,
moniker,
&_qcaRegistration);
ValidateResult(result, "Error registering QueryCancelAutoplayListener with the ROT");
runningObjectTable->Register returns S_OK, and at the end of the code block's execution the ref-count for listenerInstance is 1 (if I remove the call to runningObjectTable->Register completely, the ref-count remains 0 when qcaListener goes out of scope so this means an instance of my class remains active in the ROT).
More details: In development, my service runs with my account credentials (local administrator). Although this will probably change, it should work as it is with the current configuration.
Can anyone shed any light on this?
*- I know the documentation says I shouldn't implement IQueryCancelAutoPlay in a service but I need to do this for various reasons (business requirement, etc).
I figured it out (for those who stumble upon this answer when having a similar problem):
The service runs under a different window station and a different desktop. When the IQueryCalcelAutoPlay implementation is registered in the ROT this is done for a different desktop.
The current user's desktop shell (explorer) will not find this registration when a new USB device is inserted (as it is not registered with the current desktop).
How can I detect whenever the power cord is unplugged from electrical socket using JSR 256?
You would add javax.microedition.io.Connector.sensor to the API Permissions tab of the Application Descriptor of the project properties.
From a quick look at the specifications of the JSR:
(you might want to look for code examples, starting with Appendix D of the spec itself, the latest JavaME SDK, Sony Ericsson developer website, then google)
As always, I would be worried about fragmentation in the diverse implementations of the JSR, but here's my first idea:
import javax.microedition.sensor.*;
SensorInfo[] powerSensorInfoArray = SensorManager.findSensors("power","ambient");
//let's assume there is one SensorInfo in the array.
//open a connection to the sensor.
SensorConnection connection = (SensorConnection)Connector.open(powerSensorInfoArray[0].getUrl(), Connector.READ);
// add a DataListener to the connection
connection.setDataListener(new MyDataListener(), 1);
// implement the data listener
public class MyDataListener implements DataListener {
public void dataReceived(SensorConnection aSensor, Data[] aDataArray, boolean isDataLost) {
//let's assume there is only one channel for the sensor and no data was lost.
// figure out what kind of data the channel provides.
int dataType = aDataArray[0].getChannelInfo().getDataType();
//now, I suggest you switch on dataType and print the value on the screen
// experimentation on the JSR256 implementation you're targetting seems to be
// the only way to figure out out power data is formatted and what values mean.
//only one of the following 3 lines will work:
double[] valueArray = aDataArray[0].getDoubleValues();
int[] valueArray = aDataArray[0].getIntValues();
Object[] valueArray = aDataArray[0].getObjectValues();
// let's assume one value in the valueArray
String valueToPrint = "" + valueArray[0];
// see what happens with that and you plug or unplug the power supply cable.
}
}
You'll need to add javax.microedition.io.Connector.sensor to your MIDlet permissions.
-------EDIT------
Documentation from the JSR-256 implementation on Sony-Ericsson Satio phone (S60 5th edition):
The battery charge sensor has the following characteristics:
Quantity: battery_charge
Context type: device
URL: sensor:battery_charge;contextType=device;model=SonyEricsson
Channels: (index: name, range, unit)
0: battery_charge, 0-100, percent
1: charger_state, 0-1, boolean