I am implementing Windows MDM. In this, Device sends CSR which is PKCS#10 Certificate request.
When I go to http://certlogik.com/decoder, and decode this CSR,I get Subject as
"CN=B1C43CD0-1624-5FBB-8E54-34CF17DFD3A1\00"
This "\00", we want to remove from subject property.Because of this we are not able to install company hub app during enrolment.
I want to change this subject to any value such as "CN=myMDM".How can I change Subject property of CSR?
It is permissible to have a certificate subject differ from the subject of the PKCS#10 (i.e. CSR). See the -subj option to OpenSSL's 'req' command.
For reasons behind this ability, consider this; Your CSR is signed by your private key. The signature is used to verify that the contents of the CSR have not been modified (this includes the subject). Your public key is included in the CSR. A CA creates your cert and uses whatever parts of the CSR subject it sees fit. The cert, along with the CA-specified subject and the public key from your CSR is signed by the private key of the CA. This signature is used to verify that the contents of your cert have not been modified (this includes the CA-specified subject).
You cannot change it once you have the certificate request, as CSR's should be signed with your private key, and the signing is definitely including the subject line.
So if you change anything you need to resign, which requires you to parse the CSR. So basically you should rebuild your CSR and simply strip off the character with value 00 (null terminator character) when you supply your common name (CN).
You are left with the following options:
correctly generate the CSR, as explained above,
change the CSR, removing the zero valued byte and recalculating all the lengths, and skip verification,
create a special certificate creator that puts the correct subject like out of the CSR after verifying or skipping the signature verification of the CSR;
Related
I'm developing an OBD-II reader where I want to query requests to read PID parameters with a stm32 processor. I already understand what should go on the data field, but the ID is giving me a headache. As I have read, one must send 0x7DF to broadcast a request, and each ECU will respond with his own ID. However, I have been asked to do this within the SAE J1939 protocol, which uses the 29 bit extended identifier, and I don't know what I need to add to this ID.
As I stated in the title, could someone show me some actual data from a bus using this method? I've been searching on the internet for real frames but did not have any luck so far.
I woud also appreciate if someone could shred some light to if the OBD-II communication needs some acknowledgment to work properly.
Thanks
I would suggest you to take a look on the SAE J1939 documentation, in the more specifically on the J1939/21,J1939-71 and J1939/73.
Generally, a J1939 transport protocol response sequence can be processed as follows:
Identify the BAM frame, indicating a new sequence being initiated
(via the PGN 60416 - 0xEC00 can be reach by 0x1CECFF00 )
Extract the J1939 PGN from bytes 6-8 of the BAM payload to use as the
identifier of the new frame
Construct the new data payload by concatenating bytes 2-8 of the data
transfer frames (i.e. excl. the 1st byte)
A J1939 data transfer messages with ID 1CEBFF00 (PGN 60160 or EB00).
Above, the last 3 bytes of the BAM equal E3FE00. When reordered, these equal the PGN FEE3 aka Engine Configuration 1 (EC1). Further, the payload is found by combining the the first 39 bytes across the 6 data transfer packets/fram
The administrative control device or any device issuing the vehicle use status PID should be sensitive to the run switch status (SPN 3046 - 0xFDC0 which probably can be reach by 0xCFDC000) and any other locally defined criteria for authorized use (i.e., driver log-ons) before the vehicle use status PID is used to generate an unauthorized use alarm.
Also, you can't forget to uses a read/send to extend ID message, since that is a 24-bit.
In fact, i will suggest you to use can-utils to make your a analyses even easier. A simple can-dump or can-sniffer you can see what is coming on your broadcast.
Some car's dbc https://github.com/commaai/opendbc
The Google Cast protocol v2 has widely been reverse-engineered and is therefore already well-known. A good example of this is the Cast v2 Node library repository on GitHub which includes a detailed description of the cast v2 protocol.
However, whilst writing my own implementation of the protocol in Java using Netty, I realized that the auth response message is way more complex than described in the linked repository.
According to the repository, the message should look like:
message AuthResponse {
required bytes signature = 1;
required bytes client_auth_certificate = 2;
repeated bytes client_ca = 3;
}
However, the client sends 3 more fields. They have the indices 4, 6 and 7.
Field 4 is of wiretype VARINT and stands, as far as I know, for the SignatureAlgorithm the Cast-enabled device (Chromecast Gen2 and Chromecast Audio) has been challenged with.
Field 6 is also of type VARINT, but I have no idea what it stands for. During testing, it always had the value 0. (Maybe it stands for the client_ca certificate used for signing the client_auth_certificate?)
Field 7 is of wiretype LENGTH_DELIMITED. It is definetly not an UTF-8 encoded String since printing it out results in an unreadable mess. However, the sequence printed out contains the complete address that's also been used in the client_ca and client_auth_certificate, so I believe it has something to do with it. I've already tested whether this might be a certificate or RSA key, but both tests were negative. A file containing the raw byte sequence can be found here.
This brings me finally to my question:
Do you know what fields 6 and 7 stand for? Guesses based on the file's structure are also highly appreciated.
As I've found out, the protocol is practically open-source since the Chromium project includes the corresponding .proto-files in order to support streaming on Cast-enabled devices.
The complete protocol can be found here: https://github.com/chromium/chromium/blob/master/components/cast_channel/proto/cast_channel.proto
The structure of the AuthResponse message is therefore
message AuthResponse {
required bytes signature = 1;
required bytes client_auth_certificate = 2;
repeated bytes intermediate_certificate = 3;
optional SignatureAlgorithm signature_algorithm = 4
[default = RSASSA_PKCS1v15];
optional bytes sender_nonce = 5;
optional HashAlgorithm hash_algorithm = 6 [default = SHA1];
optional bytes crl = 7;
}
Can anyone explain to me what address(0) is in Solidity? I found the following in the docs but it doesn't really make sense to me:
If the target account is the zero-account (the account with the address 0), the transaction creates a new contract. As already mentioned, the address of that contract is not the zero address but an address derived from the sender and its number of transactions sent (the “nonce”). The payload of such a contract creation transaction is taken to be EVM bytecode and executed. The output of this execution is permanently stored as the code of the contract. This means that in order to create a contract, you do not send the actual code of the contract, but in fact code that returns that code.
http://solidity.readthedocs.io/en/develop/introduction-to-smart-contracts.html?highlight=address(0)#index-8
Within an Ethereum transaction, the zero-account is just a special case used to indicate that a new contract is being deployed. It is literally '0x0' set to the to field in the raw transaction.
Every Ethereum transaction, whether it's a transfer between two external accounts, a request to execute contract code, or a request to deploy a new contract, are encoded in the same way. A raw transaction object will look something like this:
transaction = {
nonce: '0x0',
gasLimit: '0x6acfc0', // 7000000
gasPrice: '0x4a817c800', // 20000000000
to: '0x0',
value: '0x0',
data: '0xfffff'
};
If to is set to something other than '0x0', this request will result in transferring ether to the address (if value is non-zero), and execute the function encoded in the data field. Remember, the address can either be a contract or an external account.
When the to address is the zero-address, a new contract will be created by executing the code in data (this is what is meant by "code that returns the code"). The address of the newly created contract is technically known beforehand as it's based on the address of the sender and it's current nonce. That address becomes the official address of the contract after mining.
For a pretty good read on Ethereum transactions, check out this blog post.
Note: There is also the actual Solidity code statement address(0) which is the initial value of a variable of type address. The documentation you posted, however, is referring to specifically when the to account address in a transaction is set to '0x0'.
It's not actually true that a contract creation transaction has a "to" field set to the zero address (meaning 0x00...000). This is an easy mistake to make (and I've made it too) as it is described that way in many resources.
The passage you cite from the Solidity docs were updated to state this:
If the target account is not set (the transaction does not have a
recipient or the recipient is set to null), the transaction creates a
new contract. As already mentioned, the address of that contract is
not the zero address but an address derived from the sender and its
number of transactions sent (the “nonce”).
So you can see they realized at some point that the recipient field should be empty. I've actually looked at serialized creation transactions and found 0x80 there instead of an RLP-ed zero address.
In fact, 0x80 is the RLP encoding of an empty byte array, which is what the Yellow Paper states is the recipient for a contract creation:
The address hash $T_t$ is slightly different: it is either a 20-byte
address hash or, in the case of being a contract-creation transaction
(and thus formally equal to ∅), it is the RLP empty byte sequence and
thus the member of $B_0$
As I said, this is a common source of confusion. In that vein, this GitHub PR rolling back a mistakenly "fixed" test is amusing. It has the comment:
RLP encoding of 0 is encoding of empty byte array, so 0x80 is correct.
0x00 is encoding of byte array of length 1 containing one byte 0, not
encoding of integer 0.
How does the STR-Transform transformation algorithm works for XML Signature, when working with WS Security? I need to sign the SecurityTokenReference used for the signature on a SOAP message, and this is the required transformation for the security token. I am using an x509 certificate to do the signature, so the security token is this certificate. However, in the message I only need the reference to the certificate thumbprint.
Here is the signature structure that I need to replicate, and the only bit that I am missing is the signature reference to the SecurityTokenReference:
<dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
<dsig:SignedInfo>
<dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<dsig:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<dsig:Reference URI="#Timestamp_C1Ih1AB1vpPT5uG2">
<dsig:Transforms>
<dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</dsig:Transforms>
<dsig:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<dsig:DigestValue>fVSyToUO8yS131cV8oT1h6fa69Jvtt+pKFeP4BFf1P4=</dsig:DigestValue>
</dsig:Reference>
<!-- Other signature references -->
<dsig:Reference URI="#str_U1sjQ5j8JtKnObLk">
<dsig:Transforms>
<dsig:Transform Algorithm="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#STR-Transform">
<wsse:TransformationParameters>
<dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</wsse:TransformationParameters>
</dsig:Transform>
</dsig:Transforms>
<dsig:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<dsig:DigestValue>gRa3zakGn13XISoKpekB3zl0iDqb/LmNy7+aMDtzKIY=</dsig:DigestValue>
</dsig:Reference>
</dsig:SignedInfo>
<dsig:SignatureValue>ptO...E9Q==</dsig:SignatureValue>
<dsig:KeyInfo>
<wsse:SecurityTokenReference
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:wsse11="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
wsse11:TokenType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"
wsu:Id="str_U1sjQ5j8JtKnObLk">
<wsse:KeyIdentifier
EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
ValueType="http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#ThumbprintSHA1">h5...ow=</wsse:KeyIdentifier>
</wsse:SecurityTokenReference>
</dsig:KeyInfo>
</dsig:Signature>
Can someone explain me how to do the signature for such token? The step-by-step description of the algorithm, or an example using any language/library will be good.
In this document is the description of the transformation, from page 38, but I am unable to understand how to apply it in practice.
OK, after checking Oracle's WebLogic server debug and verbose log file having a working service example and setting the flags -Dweblogic.xml.crypto.dsig.debug=true -Dweblogic.xml.crypto.dsig.verbose=true -Dweblogic.xml.crypto.keyinfo.debug=true -Dweblogic.xml.crypto.keyinfo.verbose=true -Dweblogic.wsee.verbose=* -Dweblogic.wsee.debug=* (more info here, here, here and here), thank God there was a preety good insight on how the security token was de-referenced. Basically, having a SecurityTokenReference for an x509 certificate, with a KeyIdentifier, is dereferenced as a BinarySecurityToken in this way:
<wsse:BinarySecurityToken xmlns="" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3">CertificateBase64String</wsse:BinarySecurityToken>
Some important things to notice are:
The ValueType, and thus the content of the BinarySecurityToken, is defined by the TokenType of the SecurityTokenReference. In this case, the text of the BinarySecurityToken is the x509 certificate that is referenced by the KeyIdentifier element, encoded as a base64 string.
According to the specification, the BinarySecurityToken only includes the ValueType attribute. So it should not include the EncodingType attribute, neither the Id attribute that the SecurityTokenReference has.
The same namespace prefix of the SecurityTokenReference is used. Also, the namespace for this prefix is included in the tag.
The default namespace attribute is set as empty: xmlns=""
So basically the whole SecurityTokenReference element is replaced by the new BinarySecurityToken, and this is the one to be canonicalized and hashed (to get its digest value). Beware that it is canonicalized and digested as is, so the operation may provide a wrong result if the XML is simplified by removing the empty xmlns namespace or the prefix namespace, or by changing the namespace prefix.
The example BinarySecurityToken is already canonicalized using the algorithm "http://www.w3.org/2001/10/xml-exc-c14n#", so in .NET, to get the DigestValue using the digest algorithm "http://www.w3.org/2001/04/xmlenc#sha256", is enough to do this:
System.Security.Cryptography.SHA256 sha = System.Security.Cryptography.SHA256.Create();
byte[] hash = sha.ComputeHash(Encoding.UTF8.GetBytes("<wsse:BinarySecurityToken xmlns=\"\" xmlns:wsse=\"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd\" ValueType=\"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3\">MIIF...2A8=</wsse:BinarySecurityToken>"));
string digestValue = Convert.ToBase64String(hash);
I want to encrypt a URL variable so that the user can't see or modify the information when it is passed in jsp.
This is an example URL:
localhost/somewebpage/name.jsp?id=1234&tname=Employee_March_2013
Here I want to encrypt or encode the parameters id and tname.
Could someone please help me write a short script that encodes / encrypts and then decrypts the parameters
EDIT:
I am sending this url as a attachment in email... when receiver clicks on this link their payslip information will displayed on the web page'
The best way to encode / decode in Base64 without using any third party libraries, you can use Using sun.misc.BASE64Encoder / sun.misc.BASE64Decoder.
try this snippet
String id="1234";
byte[] bytesEncoded = Base64.encodeBase64(id.getBytes());//encoding part
String encoded_id=new String(bytesEncoded);
String id1=request.getParameter("id");
byte[] valueDecoded= Base64.decodeBase64(id1);//decoding part
String decoded_id=new String(valueDecoded);
Send 'encoded_id' as a url parameter instead of passing 'id'
Your question became solvable the moment we knew that you are 'sending this url as attachment in email... when receiver click on this link their payslip is confirmed'
That means there are 3 options: encrypting, hashing and using random string(s).
In this case I recommend the random strings (or hashing) instead of encrypting. The reason is 2-fold:
You are not sending out potentially private data (for google gmail to read, for example)
random string(s) (or hashing) is simpler, shorter and safer (for this case).
Assuming you have a database containing your user-data, then you'd generate a unique random string (or hash) for that specific user/transaction. Then you store this data (you could hash it again internally) together with or linked to your user-data.
Now you only send out the link with the random string(s)/hash that is uniquely linked to the user-data.
Have a look on SO for https://stackoverflow.com/search?q=[jsp]+hash
and please, for the love of [enter deity here], be sure you read Wikipedia about 'salt' etc.!!
You do not want to make mistakes with user-payments!
Now, make a choice, set it up and return with questions should you get stuck!
EDIT:
In fact.. instead of hashing, a completely 'random' (fixed length) unique string(s) is sufficient! Better yet: or two random strings, for a two-factor check: one string for identification, one for authentication.
URLEncoder.encode(Encryption.encrypt(parameters), "UTF-8")
Always use POST method.
And even in POST method, user can see the id and can change it in browser console network tab.So that, user can see other's email attachment since you mentioned in your comment like that.
So, try to set id in jsp session and get the id in the java servlet code.
it is really good practice.