WebRTC SRTP解密

我想建立一個SRTP到RTP流轉換器，我有問題從WebRTC peerconnection我得到創建Master Key10。WebRTC SRTP解密

據我所知，與DES exchange，關鍵是交換通過SDP交換和顯示在a=crypto字段。所以，這種情況看起來非常簡單（請糾正我，如果我錯了），但最終沒用WebRTC標準化現在要求不應該使用DES（現在只有Chrome支持它，它可能在將來被刪除）。

對於DTLS有在SDP指紋領域，就是certificate desired的散列在未來交換使用[編輯：做一些閱讀後，我在想，是不是這樣的]我想想想知道指紋的能力，通過交換機中的DTLS數據包進行解析的能力，我應該可以抓住Master Key來解碼SRTP數據流，但是由於我不知道該在哪裏看，甚至100 ％肯定是否有可能。

因此，簡而言之，就是它甚至是可行的（並不進入下C++ API和創建我自己的實現的WebRTC）到與WebRTC PeerConnection在Chrome和FireFox（可能通過報文嗅探創建SRTP飼料解碼從編號SDP交換收集的信息）？[編輯：令人沮喪的是，似乎訪問密鑰（又名，主密鑰）的私人部分是不可能的...請糾正，如果我錯了]

來源

2014-03-27 Benjamin Trent

相關：[我可以在DTLS-SRTP加密中指定我自己的加密密鑰]（http://stackoverflow.com/questions/21921946/can-i-specify-my-own-encryption- key-in-dtls-srtp-encryption） – user

我相信目前唯一的選擇是使用本地API而不是主流瀏覽器實現 –

有使用OpenSSL的一些代碼，libsrtp本地API

#define SRTP_MASTER_KEY_KEY_LEN 16 
#define SRTP_MASTER_KEY_SALT_LEN 14 
static void dtls_srtp_init(struct transport_dtls *dtls) 
{ 

/* 
    When SRTP mode is in effect, different keys are used for ordinary 
    DTLS record protection and SRTP packet protection. These keys are 
    generated using a TLS exporter [RFC5705] to generate 

    2 * (SRTPSecurityParams.master_key_len + 
     SRTPSecurityParams.master_salt_len) bytes of data 

    which are assigned as shown below. The per-association context value 
    is empty. 

    client_write_SRTP_master_key[SRTPSecurityParams.master_key_len]; 
    server_write_SRTP_master_key[SRTPSecurityParams.master_key_len]; 
    client_write_SRTP_master_salt[SRTPSecurityParams.master_salt_len]; 
    server_write_SRTP_master_salt[SRTPSecurityParams.master_salt_len]; 
*/ 
    int code; 
    err_status_t  err; 
    srtp_policy_t policy; 
    char dtls_buffer[SRTP_MASTER_KEY_KEY_LEN * 2 + SRTP_MASTER_KEY_SALT_LEN * 2]; 
    char client_write_key[SRTP_MASTER_KEY_KEY_LEN + SRTP_MASTER_KEY_SALT_LEN]; 
    char server_write_key[SRTP_MASTER_KEY_KEY_LEN + SRTP_MASTER_KEY_SALT_LEN]; 
    size_t offset = 0; 

    /* 
    The exporter label for this usage is "EXTRACTOR-dtls_srtp". (The 
    "EXTRACTOR" prefix is for historical compatibility.) 
    RFC 5764 4.2. Key Derivation 
    */ 
    const char * label = "EXTRACTOR-dtls_srtp"; 

    SRTP_PROTECTION_PROFILE * srtp_profile= SSL_get_selected_srtp_profile(dtls->ssl); 

/* SSL_export_keying_material exports a value derived from the master secret, 
* as specified in RFC 5705. It writes |olen| bytes to |out| given a label and 
* optional context. (Since a zero length context is allowed, the |use_context| 
* flag controls whether a context is included.) 
* 
* It returns 1 on success and zero otherwise. 
*/ 
    code = SSL_export_keying_material(dtls->ssl, 
            dtls_buffer, 
            sizeof(dtls_buffer), 
            label, 
            strlen(label), 
            NULL, 
            0, 
            PJ_FALSE); 

    memcpy(&client_write_key[0], &dtls_buffer[offset], SRTP_MASTER_KEY_KEY_LEN); 
    offset += SRTP_MASTER_KEY_KEY_LEN; 
    memcpy(&server_write_key[0], &dtls_buffer[offset], SRTP_MASTER_KEY_KEY_LEN); 
    offset += SRTP_MASTER_KEY_KEY_LEN; 
    memcpy(&client_write_key[SRTP_MASTER_KEY_KEY_LEN], &dtls_buffer[offset], SRTP_MASTER_KEY_SALT_LEN); 
    offset += SRTP_MASTER_KEY_SALT_LEN; 
    memcpy(&server_write_key[SRTP_MASTER_KEY_KEY_LEN], &dtls_buffer[offset], SRTP_MASTER_KEY_SALT_LEN); 

    switch(srtp_profile->id) 
    { 
    case SRTP_AES128_CM_SHA1_80: 
    crypto_policy_set_aes_cm_128_hmac_sha1_80(&policy.rtp); 
    crypto_policy_set_aes_cm_128_hmac_sha1_80(&policy.rtcp); 
    break; 
    case SRTP_AES128_CM_SHA1_32: 
    crypto_policy_set_aes_cm_128_hmac_sha1_32(&policy.rtp); // rtp is 32, 
    crypto_policy_set_aes_cm_128_hmac_sha1_80(&policy.rtcp); // rtcp still 80 
    break; 
    default: 
    assert(0); 
    } 
    policy.ssrc.value = 0; 
    policy.next = NULL; 

    /* Init transmit direction */ 
    policy.ssrc.type = ssrc_any_outbound; 
    policy.key = client_write_key;  

    err = srtp_create(&dtls->srtp_ctx_rx, &policy); 
    if (err != err_status_ok) { 
    printf("not working\n"); 
    } 

    /* Init receive direction */ 
    policy.ssrc.type = ssrc_any_inbound; 
    policy.key = server_write_key;  

    err = srtp_create(&dtls->srtp_ctx_tx, &policy); 
    if (err != err_status_ok) { 
    printf("not working\n"); 
    } 

}

來源

2014-06-24 11:16:56

老兄，喜歡它！這是特定項目的一部分嗎？ –

坦克，bwtrent！這是CrystalVu SDK（http://www.integrit.com/products/240-crystalvu-video-conferencing-sdk）的一部分，它提供了與sipml5（http://sipml5.org/）的互操作性， –

我找到'SSL_export_keying_material' 哪些可以從SSL機制中獲取密鑰（在DTLS握手之後）並將其用於SRTP。

我不是專家，只是擊中就像你在牆上...

來源

2014-06-17 12:46:25 eduard

，如果這是你的情況目前還不清楚，但請注意，不能從SRTP訪問音頻/視頻（即：解密）僅僅是被動的觀察者 - 這就是傳輸加密的關鍵。

協議（DTLS-SRTP）的工作原理大致是這樣的：

每個瀏覽器都有一個唯一的密鑰對，通常在安裝時產生
每一側的fingerprint of the public part of the keypair在包括在SDP中，在提供和回答。
兩端協商DTLS連接，通過ordinary DTLS handshake，由此得出了一種會話密鑰，它是用來固定（DTLS）連接
The derived session key is used as the SRTP key

，如果你沒有訪問至少有一個密鑰對的私有部分，根本不可能解密連接。如果端點選擇在握手中使用Diffie-Hellman key exchange，被動攻擊者將無法獲取派生密鑰，即使訪問了兩個私鑰。這家酒店被稱爲forward secrecy。

訪問SRTP內容的唯一可靠方法是自己動手握手，實施活動的MITM（更改SDP上的指紋）或從瀏覽器獲取私鑰並限制DH密鑰交換（即AFAIK，是不可能的）

來源

2014-08-05 10:45:48 goncalopp

回答

相關問題