keyfile

Anonymous
2002-02-17
2002-04-25
  • Anonymous - 2002-02-17

    Can i obtain the original keyfile when i decode i file ( for re-encoding)?
    Thanks a lot

     
    • Cornel Ciocirlan

      No. The key is not in the file, only an HMAC-MD5 hash of the key and some of the data in the file.

       
    • Anonymous - 2002-02-17

      supouse that i have a encoded file, y can`t decode it, change it and re-encode it because i haven't got the keyfile?

       
      • Evvolve SRL

        Evvolve SRL - 2002-02-18

        You are right. You cannot decode/encode the file because you don't have the keyfile. You can decode the file and encode it back with a whatever random key but it is not "authenticated".

         
      • Evvolve SRL

        Evvolve SRL - 2002-02-18

        You are right. You cannot decode/encode the file because you don't have the keyfile. You can decode the file and encode it back with a whatever random key but it is not "authenticated".

         
    • Marcos Ramos

      Marcos Ramos - 2002-02-27

      When i decoded the file there where 2 md5 keys in it, can i use them to re-encode the decoded file?
      ---START---
      CmMic f5c53e241ce230a8ca79062f25aa1bef;
      CmtsMic eae8435d9092cde705efe7871e53b64e;
      ---END---

      can i use this ?

       
      • Santiago Balseiro

        no, because they only provide information about the previous encoding.
        your new configuration will have new MICs (still only the CTMS-MIC is key-dependant, and this is the one verified against the CTMS). the CM-MIC is used by the CM to test the config file integrity.

        *********************
        A question:
        private keys can be upto 64-byte long. but does anyody know if CTMSops usally use 64-byte long random generated keys or just simple mnemonic alphanumeric keys?

         
        • Evvolve SRL

          Evvolve SRL - 2002-03-05

          They can use whatever they like ... I suppose they use random keys most of the time since this is not something you would need every day.

          Andii

           
          • Santiago Balseiro

            I was thinking of a brute-force attack with a reduced alphabet, but it seems that the attack would be infeasable... O(256^64) is quite alot...

            MD5 benchmarks report 48 MB/S on a pentium (RFC 1810 and "Performance Analysis of MD5-Joseph D. Touch"). If we consider that the length of the data is 512 bytes aprox (bytes of the configuration setting fields plus CM-MIC), it will process about 100000 keys per second, taking 10^143 years!!!!

            any help?

             
        • Johnathan Leppert

          Wouldn't it seem plausable to generate a new Cm MIC corresponding to the edited file (a new hash), and repackage the old Cm Ts MIC? The Cm Ts MIC is the only hash that is key dependant and the CM doesn't touch it -- it doesn't have the CMTS key anyway, right?

          When I tried directly transposing the two hashes from a file that worked onto one I edited, I got an as expected Failed Message Integrity Check on the modem diag. However, what would happen if we generated a new MD5 to describe the new file and transposed the old Cm Ts MIC?

          The CM only sends one key, the Cm Ts MIC to the CMTS during a REG-REQ, right? So it should work??

          Anyone??

           
          • Santiago Balseiro

            Briefing:
            The encoded file is a succession of TLVs (type-lenght-value) describing the desired cable modem (CM) configuration. The last two TLVs hold message integrity check: the CM-MIC and the CTMS-MIC respectively. The CM-MIC is used by the CM to test the config file integrity. The CTMS-MIC is key-dependant and verified against the cable modem terminal server (CMTS) during the registration process. The registration is needed to access the service.

            The CMTS-MIC is calculated with the HMAC-MD5 (rfc2104) hash algorithm. The input data is: the key, the CM-MIC and some sensitive TLVs entries including the MaxCPE and MaxRates. All this information (including which TLVs are picked) is described in the DOCSIS 1.0 Radio Frequency Interface Specification by www.cablelabs.com.

            During the REG-REQ process the CM sends to the CMTS the CMTS-MIC and ALL the information needed to recalculate it (i.e.: CM-MIC and TLVs). Then the CMTS recalculates the CMTS-MIC with this info and the key stored within the CTMS. The registration succeeds if the hashes match.

            The problem:
            So if you encode your file properly and change the CMTS-MIC to a previous working one, it will still fail. Because the CMTS-MIC calculated by the CMTS won't match yours! (they may have the same key, but they won't have the same TLVs and the corresponding CM-MIC).

             
            • Johnathan Leppert

              panta,

              Thanks for the explanation. That clears up a lot; It seems pretty full-proof. I am wondering about your comments on a site www.surfboardhack.com. The guy there is writing a distributed MD5 cracking program and estimates it would take only a few days if he can recruit 100 computers with at least 1 GHz processing power, to crack a certain key via a brute force search of the key space. I'm going to load it on 20 computers I have access to with 500 MHz Alpha processors, and I am wondering if it's worth the investment.

               
    • Anonymous - 2002-03-13

      there is no way to edit the file and chage the CmMic and the CmTsMic?

       
      • Santiago Balseiro

        The last two TLV (mostly?) hold the CM-Mic and CMTS-Mic respectively. So you have to look for the hex string:

        06 10 <CM-Mic=16 bytes> 07 10 <CMTS-Mic=16 bytes> FF 00 00 00

        FF 00 00 00 is the file terminator

         
        • Anonymous - 2002-03-17

          so how can we make the newly-encoded file 'authenticated', or fool the modem into believe it is authenticated?

          where is the original keyfile stored?
          thanks,
          Dave

           
          • Santiago Balseiro

            There is no way to make the newly-encoded file authenticated unless that you have the key-file. And for those of you wondering, the key-file is not included within the previous file. Only the hash of the key-file rehashed with some data is included (MD5-MAC rfc2104). But there is no way to get it right from it, except for a quite infeasible brute-force attack (read my previous post).

            Maybe you heard from someone that tried with any key-file and it worked successfully. It is due to the fact that some cable modem companies do not authenticate the file each time cablemodem is restarted (although nowadays most of them do!).
              panta

             
    • Anonymous - 2002-03-16

      when i try to encode this using keyfile:

      Main {
      NetworkAccess 1;
      MaxCPE 8;
      ClassOfService {
      ClassID 1;
      MaxRateDown 100000000;
      MaxRateUp 100000000;
      PriorityUp 7;
      GuaranteedUp 0;
      MaxBurstUp 1600;
      PrivacyEnable 0;
      }
      SnmpMibObject .1.3.6.1.2.1.69.1.6.3.0 = 2
      ;
      SnmpMibObject .1.3.6.1.2.1.69.1.6.4.1.2.1 = 4
      ;
      SnmpMibObject .1.3.6.1.2.1.69.1.6.4.1.3.1 = 1
      ;
      SnmpMibObject .1.3.6.1.2.1.69.1.6.4.1.4.1 = 0
      ;
      SnmpMibObject .1.3.6.1.2.1.69.1.6.4.1.5.1 = 3
      ;
      SnmpMibObject .1.3.6.1.2.1.69.1.6.4.1.6.1 = 1
      ;
      SnmpMibObject .1.3.6.1.2.1.69.1.6.4.1.7.1 = IpAddress: 0.0.0.0
      ;
      SnmpMibObject .1.3.6.1.2.1.69.1.6.4.1.8.1 = IpAddress: 0.0.0.0
      ;
      SnmpMibObject .1.3.6.1.2.1.69.1.6.4.1.9.1 = IpAddress: 224.0.0.0
      ;
      SnmpMibObject .1.3.6.1.2.1.69.1.6.4.1.10.1 = IpAddress: 240.0.0.0
      ;
      SnmpMibObject .1.3.6.1.2.1.69.1.6.4.1.11.1 = 256
      ;
      SnmpMibObject .1.3.6.1.2.1.69.1.6.4.1.12.1 = 0
      ;
      SnmpMibObject .1.3.6.1.2.1.69.1.6.4.1.13.1 = 65535
      ;
      SnmpMibObject .1.3.6.1.2.1.69.1.6.4.1.14.1 = 0
      ;
      SnmpMibObject .1.3.6.1.2.1.69.1.6.4.1.15.1 = 65535
      ;
      CmMic e12786088b81446dd7bc138ede2bfab2;
      CmtsMic 8c008558ce53ff2070237f0fe6453e4b;
      /* EndOfDataMkr */
      }

      i get this error

      docsis.exe: at line 6, MaxRateDown value 100000000 out of range 0-29952

      the original decoded file had:

      MaxRateDown 10000000;

       
    • Evvolve SRL

      Evvolve SRL - 2002-03-18

      The MaxRateDown can be between 0 and 52000000. 100 Mbit/s is illegal (the maximum downstream rate on cable networks is 52 megs). The original file must have been illegal :).

      If you want to increase the limit edit docsis_symtable.h and find the line with MaxRateDown and replace 52000000 with 0xFFFFFFFF for example (that would be the maximum of 4.2 Gbit/s :)).

       

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks