|
| 1 | +package org.phpsoap.interop; |
| 2 | + |
| 3 | +import org.apache.wss4j.common.WSEncryptionPart; |
| 4 | +import org.apache.wss4j.common.crypto.Crypto; |
| 5 | +import org.apache.wss4j.dom.WSConstants; |
| 6 | +import org.apache.wss4j.dom.message.WSSecDKEncrypt; |
| 7 | +import org.apache.wss4j.dom.message.WSSecDKSign; |
| 8 | +import org.apache.wss4j.dom.message.WSSecEncrypt; |
| 9 | +import org.apache.wss4j.dom.message.WSSecEncryptedKey; |
| 10 | +import org.apache.wss4j.dom.message.WSSecHeader; |
| 11 | +import org.apache.wss4j.dom.message.WSSecSignature; |
| 12 | +import org.w3c.dom.Document; |
| 13 | + |
| 14 | +import javax.crypto.KeyGenerator; |
| 15 | +import javax.crypto.SecretKey; |
| 16 | +import java.util.List; |
| 17 | + |
| 18 | +/** |
| 19 | + * The WS-SecurityPolicy SymmetricBinding: one session key, wrapped once in an {@code xenc:EncryptedKey}, |
| 20 | + * keying the signature (as an HMAC) and the encryption both. Unlike the asymmetric flow, where signing and |
| 21 | + * encryption are independent blocks that happen to sit in the same header, here they are two uses of one key, |
| 22 | + * so one class emits both. |
| 23 | + * |
| 24 | + * <p>Two things about the wire shape are the reason this exists. First, the {@code xenc:ReferenceList} is a |
| 25 | + * SIBLING of the {@code xenc:EncryptedKey} rather than a child of it, which is what lets a signature cover the |
| 26 | + * key element for token protection without the encryption block writing into that same element afterwards. |
| 27 | + * The price is a {@code ds:KeyInfo} on every {@code xenc:EncryptedData}, since a detached reference list no |
| 28 | + * longer says which key opens what. Second, the key is named by {@code #EncryptedKeySHA1}, the digest of the |
| 29 | + * key's CIPHER bytes, which is the one identifier both peers can compute: the session key itself is known |
| 30 | + * only to the sender until the recipient unwraps it. |
| 31 | + * |
| 32 | + * <p>Header layout falls out of WSS4J prepending each block it builds, and the resulting document order is |
| 33 | + * load-bearing rather than cosmetic. A reader walking the header meets the {@code xenc:EncryptedKey} first, so |
| 34 | + * it holds the session key by the time the {@code xenc:ReferenceList} asks it to decrypt, and the Body is |
| 35 | + * plaintext again by the time the {@code ds:Signature} asks it to verify. |
| 36 | + * |
| 37 | + * <p>With {@code derivedkeys=true} each block gets its own {@code wsc:DerivedKeyToken} off that single |
| 38 | + * {@code xenc:EncryptedKey} instead, P_SHA1 over a per-token nonce, which is what {@code sp:RequireDerivedKeys} |
| 39 | + * asks for, and what a live peer has been seen sending. |
| 40 | + */ |
| 41 | +final class SymmetricBinding { |
| 42 | + |
| 43 | + private final Crypto crypto; |
| 44 | + private final ScenarioConfig config; |
| 45 | + |
| 46 | + SymmetricBinding(Crypto crypto, ScenarioConfig config) { |
| 47 | + this.crypto = crypto; |
| 48 | + this.config = config; |
| 49 | + } |
| 50 | + |
| 51 | + /** |
| 52 | + * @param signedParts what the signature covers, decided by the caller so the asymmetric and symmetric |
| 53 | + * flows cannot drift on it |
| 54 | + */ |
| 55 | + void apply(Document document, WSSecHeader header, List<WSEncryptionPart> signedParts) throws Exception { |
| 56 | + // Santuario must be initialised before the encryption classes are used directly; the engine-based |
| 57 | + // paths trigger it lazily, this one does not. |
| 58 | + org.apache.xml.security.Init.init(); |
| 59 | + |
| 60 | + SecretKey sessionKey = sessionKey(); |
| 61 | + WSSecEncryptedKey encryptedKey = encryptedKey(header); |
| 62 | + encryptedKey.prepare(crypto, sessionKey); |
| 63 | + |
| 64 | + if (config.requireDerivedKeys) { |
| 65 | + deriveAndApply(document, header, signedParts, encryptedKey, sessionKey); |
| 66 | + } else { |
| 67 | + applyDirectly(document, header, signedParts, encryptedKey, sessionKey); |
| 68 | + } |
| 69 | + |
| 70 | + // Last, so it lands in front of everything that needs it. |
| 71 | + encryptedKey.prependToHeader(); |
| 72 | + } |
| 73 | + |
| 74 | + /** Sign and encrypt with the session key itself, naming it by the digest of its cipher bytes. */ |
| 75 | + private void applyDirectly( |
| 76 | + Document document, |
| 77 | + WSSecHeader header, |
| 78 | + List<WSEncryptionPart> signedParts, |
| 79 | + WSSecEncryptedKey encryptedKey, |
| 80 | + SecretKey sessionKey) throws Exception { |
| 81 | + |
| 82 | + WSSecSignature signature = new WSSecSignature(header); |
| 83 | + signature.setKeyIdentifierType(WSConstants.ENCRYPTED_KEY_SHA1_IDENTIFIER); |
| 84 | + signature.setEncrKeySha1value(encryptedKey.getEncryptedKeySHA1()); |
| 85 | + signature.setSecretKey(sessionKey.getEncoded()); |
| 86 | + signature.setSignatureAlgorithm(macAlgorithm()); |
| 87 | + signature.setDigestAlgo(WSConstants.SHA256); |
| 88 | + signature.setSigCanonicalization(Signer.canonicalizationUri(config.canonicalization)); |
| 89 | + signature.getParts().addAll(signedParts); |
| 90 | + signature.build(crypto); |
| 91 | + |
| 92 | + WSSecEncrypt encrypt = new WSSecEncrypt(header); |
| 93 | + // The key is already on the wire in the block above, so this one references it rather than wrapping a |
| 94 | + // second copy. That is also what makes WSS4J emit the reference list detached instead of nested. |
| 95 | + encrypt.setEncryptSymmKey(false); |
| 96 | + encrypt.setKeyIdentifierType(WSConstants.ENCRYPTED_KEY_SHA1_IDENTIFIER); |
| 97 | + // Without this WSS4J would name the session key by its own digest rather than by the digest of the |
| 98 | + // cipher bytes, which is an identifier no recipient can reproduce. |
| 99 | + encrypt.setCustomReferenceValue(encryptedKey.getEncryptedKeySHA1()); |
| 100 | + encrypt.setSymmetricEncAlgorithm(Encryptor.dataAlgorithm(config.dataEncryptionAlgorithm)); |
| 101 | + encrypt.getParts().add(bodyContent(document)); |
| 102 | + encrypt.build(crypto, sessionKey); |
| 103 | + } |
| 104 | + |
| 105 | + /** Derive one key per block from the session key, each announced by its own wsc:DerivedKeyToken. */ |
| 106 | + private void deriveAndApply( |
| 107 | + Document document, |
| 108 | + WSSecHeader header, |
| 109 | + List<WSEncryptionPart> signedParts, |
| 110 | + WSSecEncryptedKey encryptedKey, |
| 111 | + SecretKey sessionKey) throws Exception { |
| 112 | + |
| 113 | + WSSecDKSign signature = new WSSecDKSign(header); |
| 114 | + signature.setTokenIdentifier(encryptedKey.getId()); |
| 115 | + signature.setCustomValueType(WSConstants.WSS_ENC_KEY_VALUE_TYPE); |
| 116 | + signature.setSignatureAlgorithm(macAlgorithm()); |
| 117 | + signature.setDigestAlgorithm(WSConstants.SHA256); |
| 118 | + signature.setSigCanonicalization(Signer.canonicalizationUri(config.canonicalization)); |
| 119 | + signature.getParts().addAll(signedParts); |
| 120 | + signature.build(sessionKey.getEncoded()); |
| 121 | + |
| 122 | + WSSecDKEncrypt encrypt = new WSSecDKEncrypt(header); |
| 123 | + encrypt.setTokenIdentifier(encryptedKey.getId()); |
| 124 | + encrypt.setCustomValueType(WSConstants.WSS_ENC_KEY_VALUE_TYPE); |
| 125 | + encrypt.setSymmetricEncAlgorithm(Encryptor.dataAlgorithm(config.dataEncryptionAlgorithm)); |
| 126 | + encrypt.getParts().add(bodyContent(document)); |
| 127 | + encrypt.build(sessionKey.getEncoded()); |
| 128 | + } |
| 129 | + |
| 130 | + /** |
| 131 | + * The signature here is keyed by the session key, so its algorithm has to be a keyed MAC. Refused rather |
| 132 | + * than quietly substituted: an RSA name reaching this path means the caller believes a certificate is |
| 133 | + * signing, and a message that says HMAC while the sender thought otherwise is the confusion this whole |
| 134 | + * feature has to avoid. |
| 135 | + */ |
| 136 | + private String macAlgorithm() { |
| 137 | + if (!config.signatureAlgorithm.startsWith("HMAC_")) { |
| 138 | + throw new IllegalArgumentException( |
| 139 | + "a symmetric binding needs an HMAC signature.algorithm, got: " + config.signatureAlgorithm); |
| 140 | + } |
| 141 | + |
| 142 | + return Signer.signatureAlgorithm(config.signatureAlgorithm); |
| 143 | + } |
| 144 | + |
| 145 | + private WSSecEncryptedKey encryptedKey(WSSecHeader header) { |
| 146 | + WSSecEncryptedKey encryptedKey = new WSSecEncryptedKey(header); |
| 147 | + encryptedKey.setUserInfo(config.encryptionRecipientAlias); |
| 148 | + encryptedKey.setKeyIdentifierType(Encryptor.keyIdentifierType(config.encryptionKeyReference)); |
| 149 | + encryptedKey.setKeyEncAlgo(Encryptor.keyAlgorithm(config.keyEncryptionAlgorithm)); |
| 150 | + encryptedKey.setDigestAlgorithm(Encryptor.oaepDigestAlgorithm(config.oaepDigest)); |
| 151 | + encryptedKey.setMGFAlgorithm(Encryptor.oaepMgfAlgorithm(config.oaepDigest)); |
| 152 | + |
| 153 | + return encryptedKey; |
| 154 | + } |
| 155 | + |
| 156 | + /** |
| 157 | + * Both AES-256-GCM and AES-256-CBC take a 256-bit AES key, and a keyed MAC accepts a key of any length, so |
| 158 | + * one generator serves every algorithm combination the scenario offers. |
| 159 | + */ |
| 160 | + private static SecretKey sessionKey() throws Exception { |
| 161 | + KeyGenerator generator = KeyGenerator.getInstance("AES"); |
| 162 | + generator.init(256); |
| 163 | + |
| 164 | + return generator.generateKey(); |
| 165 | + } |
| 166 | + |
| 167 | + private static WSEncryptionPart bodyContent(Document document) { |
| 168 | + String namespace = document.getDocumentElement().getNamespaceURI(); |
| 169 | + |
| 170 | + return new WSEncryptionPart( |
| 171 | + WSConstants.ELEM_BODY, |
| 172 | + namespace != null ? namespace : WSConstants.URI_SOAP12_ENV, |
| 173 | + "Content"); |
| 174 | + } |
| 175 | +} |
0 commit comments