Tag Archives: zrtp

RFC 6189: ZRTP cuối cùng là một tiêu chuẩn!

Cuối cùng ZRTP đã được chỉ định chuyển nhượng chính thức RFC, RFC6189 ZRTP: Truyền thông đường Hiệp định chính cho Unicast an toàn RTP.

Nó đã là một sự phụ thuộc SRTP với AES 256bit kích thước khóa mà bây giờ đã được định nghĩa là RFC6188 .

Đó là thú vị để xem RFC cuối cùng phát hành, vì nó là một cột mốc quan trọng để thiết lập ZRTP như là tiêu chuẩn chính thức để mã hóa end-to-end giống như PGP đã được cho email.

Bây giờ bất kỳ tổ chức trên thế giới sẽ chính thức có thể thực hiện ZRTP để mã hóa giọng nói giao thức end-to-end

Hiện tại 3 triển khai công khác nhau của giao thức ZRTP tồn tại:

Mỗi người trong số họ cung cấp tính năng khác nhau của giao thức, nhưng quan trọng nhất được biết là có khả năng làm.

Một làn sóng mới đang đến với thế giới mã hóa giọng nói, irrupting thành một vùng màu xám mà hầu hết các công ty làm hệ thống mã hóa điện thoại đã được thực hiện mã hóa tùy chỉnh.

Bây giờ có một tiêu chuẩn được thiết lập và có rất ít lý do còn lại để thực hiện một cái gì đó khác nhau.

Hurra ông Zimmermann và tất cả các cộng đồng của công ty (như PrivateWave ) và cá nhân (như Werner Dittmann ) mà làm việc trên nó!

Ngày nay nó là một ngày tuyệt vời, loại đó của công nghệ hiện nay chính thức và cũng có nhiều thực hiện!

Philip, bạn đã làm nó một lần nữa, lời khen ngợi của tôi để tinh thần tinh khiết của bạn và xác định:-)

Zorg, mới ++ C và Java ZRTP thực hiện công bố công khai

Hi all, ngày hôm nay tại PrivateWave Italia SpA, công ty tiếng ý tham gia vào phát triển công nghệ để bảo vệ sự riêng tư và an ninh thông tin trong viễn thông giọng nói mà tôi CTO, chúng tôi phát hành Zorg, một ZRTP mã nguồn mở thực hiện giao thức mới có sẵn để tải về từ http: // www. zrtp.org .

ZRTP [1] cung cấp cho end-to-end trao đổi khóa với Elliptic Curve Diffie-Hellmann và mã hóa 384bit AES-256 SRTP.

Zorg đã được ban đầu được phát triển và thực hiện trong các sản phẩm mã hóa giọng nói của PrivateGSM PrivateWave có sẵn cho các nền tảng sau đây: Blackberry, Nokia và iOS (iPhone).

Zorg C ++ đã được tích hợp với VoIP PJSIP mã nguồn mở [2] SDK và nó cung cấp như tích hợp bản vá chống PJSIP 1.8.5. Nó đã được thử nghiệm trên iPhone, Symbian, Windows, Linux và Mac OS X.

Zorg Java đã được tích hợp trong một phiên bản tùy chỉnh của MJSIP [3] mã nguồn mở trên nền tảng Blackberry SDK và nó bao gồm tối ưu hóa sử dụng bộ nhớ cần thiết để giảm sát hoạt động thu gom rác tối thiểu.

Cả hai nền tảng đã tách ra và mô-đun mã hóa trở lại để kết thúc việc thực hiện thuật toán mã hóa có thể dễ dàng trao đổi với những người khác.

. Zorg được cấp phép theo GNU AGPL và mã nguồn có sẵn trên github tại https://github.com/privatewave/ZORG .

Chúng tôi đang phát hành nó theo mã nguồn mở và trong sự gắn kết với cách tiếp cận của chúng tôi để bảo mật [4] như chúng tôi thực sự hy vọng rằng nó có thể hữu ích cho hệ sinh thái nguồn mở để tạo ra hệ thống mã hóa tiếng nói mới trong hỗ trợ của tự do ngôn luận.

Hơn 20 mã nguồn mở phần mềm mã hóa VoIP pjsip dựa trên và một số viết bằng Java có thể được hưởng lợi trực tiếp từ Zorg phát hành.

Chúng tôi sẽ rất vui khi nhận được đề nghị hợp tác, hội nhập mới, mật mã mới trở lại-kết thúc, lỗi trinh sát và bất cứ điều gì hữu ích để cải thiện và để ZRTP khẳng định như là tiêu chuẩn mã hóa giọng nói.

Zorg có sẵn từ http://www.zrtp.org .

[1] ZRTP: http://en.wikipedia.org/wiki/ZRTP
[2] PJSIP: http://www.pjsip.org
[3] MJSIP: http://www.mjsip.org
[4] phương pháp tiếp cận an ninh: http://www.privatewave.com/security/approch.html

PrivateGSM: Blackberry thoại di động mã hóa / iPhone / Nokia với ZRTP hoặc SRTP / SDES

Tôi hoàn toàn tránh sử dụng blog cá nhân của mình để làm cho quảng cáo của bất kỳ loại sản phẩm.

Lúc đó nó không phải là khác nhau, nhưng tôi muốn nói với bạn sự thật về sản phẩm tôi làm việc trên mà không cần tiếp thị ưa thích, nhưng ở kỹ thuật.

Hôm nay, tại PrivateWave nơi tôi CTO và đồng sáng lập , chúng tôi phát hành sản phẩm mã hóa VoIP di động công khai cho Blackberry, iPhone và Nokia:

  • The 1st bao giờ Blackberry mã hóa VoIP với ZRTP - PrivateGSM VoIP chuyên nghiệp
  • The 1st bao giờ iPhone mã hóa VoIP với ZRTP - PrivateGSM VoIP chuyên nghiệp
  • The 1st bao giờ Blackberry mã hóa VoIP khách hàng với SRTP với trao đổi khóa SDES trên SIP / TLS - PrivateGSM VoIP doanh nghiệp

logo-privatewave-colore.png

Tại PrivateWave chúng tôi sử dụng một cách tiếp cận khác nhau đối với hầu hết các công ty mã hóa giọng nói trên mạng, đọc của chúng tôi cách tiếp cận đối với an ninh .

Sự phù hợp của sản phẩm này trong công nghệ và công nghiệp cảnh quan có thể được tóm tắt như sau:

  • Đó là công ty mã hóa giọng nói đầu tiên chỉ sử dụng giao thức bảo mật tiêu chuẩn (và chúng tôi kỳ vọng thị trường sẽ phản ứng, vì nó rõ ràng là công nghệ độc quyền đến từ di sản của CSD không thể cung cấp cùng một giá trị)
  • Đó là cách tiếp cận đầu tiên trong mã hóa giọng nói để chỉ sử dụng mã nguồn mở và công cụ mã hóa tiêu chuẩn
  • Đó là phương pháp mã hóa giọng nói đầu tiên cung cấp mô hình bảo mật khác nhau sử dụng công nghệ khác nhau (end-to-end cho ZRTPend-to-trang web cho SRTP )

Những bộ các khách hàng an toàn di động, được thiết kế để sử dụng bảo vệ chuyên nghiệp chỉ sử dụng công nghệ viễn thông và an ninh tốt nhất, cung cấp một mức độ bảo vệ cao cùng với hiệu suất tốt cũng trong điều kiện mạng xấu:

  • : Nhiều mô hình bảo mật end-to-end mã hóa với ZRTPend-to-trang web mã hóa với SRTP
  • Mã hóa giọng nói
  • Tín hiệu mã hóa
  • Giấy chứng nhận kỹ thuật số kiểm tra nghiêm ngặt của SIP / TLS (99% khách hàng voip không làm sâu nghiêm ngặt TLS kiểm tra)
  • AMR mã hóa 4.75kbit (cùng công nghệ và codec âm thanh của cuộc gọi điện thoại GSM tiêu chuẩn)
  • Cực kỳ tối ưu hóa jitter đệm (Nó hoạt động ngay cả trong GPRS và thông qua WiFi qua vệ tinh)
  • Tự động luôn luôn-on kết nối lại bằng cách sử dụng kỹ thuật Nokia chờ để tiết kiệm pin mạnh mẽ

Các ứng dụng là:

icona-pgsm.png

Các thiết bị di động hỗ trợ:

Về ZRTP chúng tôi quyết định nhấn mạnh và kéo dài tất cả các tính năng bảo mật và hoang tưởng của giao thức với một số bổ sung nhỏ:

  • Chỉ sử dụng Elliptic Curve Diffie Hellmann (ECDH) 384bit là một phần của NSA Suite B ( Không Koblitz ECDH-571 đường cong! )
  • Sử dụng AES256 trong chế độ CTR
  • Không kiểm tra bộ nhớ cache và liên tục chính
  • Hội nhập addressbook nghiêm ngặt mở rộng đối với RFC với kiểm tra thêm hoang tưởng
  • Tất cả các cảnh báo bảo mật và lỗi bảo mật gây ra các cuộc gọi đến được gác máy, bộ nhớ cache xóa và cảnh báo người sử dụng để tái kiểm tra an ninh ZRTP
  • Sử dụng số ngẫu nhiên phát theo đúng yêu cầu bảo mật FIPS bằng cách sử dụng Phisical Nguồn Entropy (Microphone)

Chặt chẽ hội nhập sổ địa chỉ của chúng tôi, vượt xa ZRTP RFC đặc điểm kỹ thuật, đó có thể dễ bị tấn công nhất định khi được sử dụng trên điện thoại di động vì hành vi người dùng không nhìn vào màn hình điện thoại di động.

Cách paranoy của chúng tôi sử dụng ZRTP giảm thiểu điều kiện như vậy, chúng tôi sẽ viết về sau này và / hoặc sẽ thêm các chi tiết cụ thể cho RFC nhận.

Một số từ trên PrivateGSM chuyên nghiệp với mã hóa end-to-end với ZRTP

Đọc tờ kỹ thuật đó!

Để tải về nó bấm vào đây và chỉ cần đặt số điện thoại của bạn

Đó là kết quả của công việc khó khăn của tất cả các nhân viên rất có tay nghề của tôi (16 người làm việc này 6 dự án cho 3 nền tảng khác nhau) trên các công nghệ khó khăn (mã hóa giọng nói) trong một môi trường hoạt động khó khăn (mạng di động bẩn và hệ điều hành điện thoại di động bẩn) để biết thêm hơn 2 năm.

Tôi rất tự hào về đội ngũ nhân viên của chúng tôi!

Điều gì tiếp theo?

Trong những tuần tiếp theo, bạn sẽ thấy phát hành các thiết lập chính của tài liệu như tích hợp với dấu hoa thị, freeswitch và an ninh Bật khác PBX, cùng với một số tin tức công nghệ bảo mật khác thú vị mà tôi chắc chắn sẽ được chú ý;)

Nó đã được một công việc khó khăn và nhiều hơn nữa đã được thực hiện nhưng tôi tin tưởng rằng sự an toàn và mã nguồn mở cộng đồng sẽ thích các sản phẩm và tiếp cận minh bạch của chúng tôi cũng quan trọng với các phiên bản mở và tích hợp mã nguồn mở mà làm cho một rất trung lập về chính trị công nghệ (backdoor miễn phí) .

Không phải mọi đường cong elliptic là như nhau: máng trên ECC bảo mật

 Phân tích bảo mật ECC đường cong và sự lựa chọn của riêng tôi

vn9jna1BdgrzDCYNBJHi09q09q.jpg

Hầu hết sử dụng mật mã hiện đại Elliptic Curve mật mã (ECC) rằng, với một kích thước phím nhỏ hơn và làm giảm sức mạnh tính toán, cung cấp cho sức mạnh tương đương với hệ thống an ninh mật mã truyền thống được gọi là DH (Diffie-Hellman) hoặc RSA (Rivest, Shamir và Adleman).

Không phải ai cũng biết rằng mã hóa ECC được lựa chọn cho các ứng dụng mã hóa tương lai và thậm chí TLS / SSL (mã hóa được sử dụng để bảo vệ các trang web) được chuyển đến ECC.

Tôi thấy rất nhiều cái gọi là "sản phẩm mã hóa độc quyền" mà bỏ rơi RSA và DH để đi với ECC lựa chọn thay thế, mà có xu hướng tùy ý sử dụng ECC bit kích thước khóa mà không cần quy định cụ thể mà loại ECC mật được sử dụng.

Tuy nhiên có một rất nhiều rắc rối xung quanh đường cong Elliptic, với rất nhiều tên gọi khác nhau và kích thước quan trọng làm khó khăn cho một phi mã hóa kinh nghiệm người sử dụng để làm cho nhân vật của mình khi đánh giá một số nội dung mật.

Do sự nhầm lẫn như vậy khuếch tán tôi quyết định làm cho phân tích của mình để tìm ra được những đường cong mã hóa ECC tốt nhất và phải ECC kích thước chìa khóa để sử dụng.

Phân tích này muốn cung cấp cho một ngành công nghiệp bảo mật dựa trên lựa chọn của các đường cong khác nhau và độ dài khoá, để lại những cân nhắc phân tích toán học và mật mã đã được đã được thực hiện trong những năm qua, tổng kết những sự lựa chọn khác nhau được thực hiện trong một số tiêu chuẩn và các giao thức an ninh.

Đầu tiên kết luận.

Từ những phân tích của tôi chỉ có những đường cong ECC dưới đây sẽ được xem xét để sử dụng trong các hệ thống mã hóa vì là người duy nhất được lựa chọn giữa các cơ quan khác nhau (ANSI, NSA, SAG, NIST, ECC BrainPool), các tiêu chuẩn giao thức bảo mật khác nhau (IPSec, OpenPGP, ZRTP, Kerberos, SSL / TLS) và là người duy nhất phù hợp với yêu cầu bảo mật NSA Suite B (tiêu chuẩn de-facto cũng cho môi trường quân sự của NATO):

  • Elliptic Thủ đường cong 256 bit - P-256
  • Elliptic Thủ đường cong 384 bit - P-384

với các tùy chọn, chỉ cần cho thực sự hoang tưởng rằng muốn nhận được thêm bit chính kích thước, vẫn không được coi là hữu ích:

  • Elliptic Thủ đường cong 521 bit - P-521

Tôi muốn nói rằng đường cong Koblitz nên tránh, trong bất kỳ kích thước khóa (163/283/409/571) khi họ không có đủ bảo hành trên mật hoạt động phân tích và hiệu quả đó là:

  • Không nằm trong lựa chọn mật mã Suite B-NSA
  • Không nằm trong lựa chọn ECC Brainpool
  • Không nằm trong lựa chọn ANSI X9.62
  • Không nằm trong lựa chọn mở rộng OpenPGP ECC
  • Không một phần của Kerberos mở rộng lựa chọn đường cong ECC

Tôi mời độc giả theo trough phân tích của tôi để hiểu được nguyên tắc cơ bản mà có thể được hiểu thậm chí không có nền tảng kỹ thuật sâu sắc nhưng ít nhất với một nền tảng công nghệ tốt một số bit cơ bản của mật mã.

 Ở đây chúng ta đi với các phân tích
 

Mục tiêu của tôi là để thực hiện một phân tích về những gì / làm thế nào cộng đồng khoa học và an ninh mở chọn hệ thống mật mã ECC để sử dụng trong giao thức bảo mật và các tiêu chuẩn theo quy định của IETF RFC (những người xác định các tiêu chuẩn Internet trong một cách cởi mở và đánh giá ngang hàng).

Dưới đây là một tập hợp các RFC giới thiệu ECC vào hệ thống hiện tại mà có được phân tích để hiểu những gì tốt hơn để sử dụng và những gì tốt hơn để loại trừ:

  • RFC5639 : Curves ECC Brainpool Standard & đường cong hệ
  • RFC4869 : NSA Suite B Cryptographic Suites cho IPsec
  • RFC5430 : Hồ sơ NSA Suite B cho Transport Layer Security (TLS)
  • RFC5008 : NSA Suite B trong an toàn / Multipurpose Internet Mail Extensions (S / MIME)
  • RFC3766 : Xác định điểm mạnh Đối với khóa công khai được sử dụng cho Trao đổi đối xứng phím
  • RFC5349 : Elliptic Curve Cryptography (ECC) Hỗ trợ cho Public Key Cryptography cho xác thực ban đầu trong Kerberos (PKINIT)
  • RFC4492 : Elliptic Curve Cryptography (ECC) Cipher Suites cho Transport Layer Security (TLS)
  • Mã hóa giọng nói ZRTP bởi Philip Zimmermann ECC đường cong
  • ECC trong OpenPGP (dự thảo d bè-jivsov-OpenPGP-ecc-06 )
  • ECC Curves lựa chọn bởi Microsoft cho thông minh Kerberos đăng nhập

Chúng tôi sẽ sử dụng sự lựa chọn của các nhà khoa học xác định Internet Security Nghị định thư thực hiện một phần trong đánh giá của chúng tôi.
Ngoài ra nó phải được hiểu rằng việc lựa chọn đường cong đến từ các cơ quan khác nhau thực hiện lựa chọn của riêng mình Curves để nói cho ngành công nghiệp gì để sử dụng và những gì để bỏ qua:

Chúng tôi sẽ sử dụng sự lựa chọn của các nhà khoa học xác định các yêu cầu an ninh trong các cơ quan tiêu chuẩn hóa để thực hiện một phần trong đánh giá của chúng tôi.
Ngoài ra, một cái gì đó mà hầu hết mọi người không biết, nhưng là nó rất phù hợp với phân tích của chúng tôi, là có những loại khác nhau của ECC đường cong mật mã và "kích cỡ" của nó khác nhau tùy thuộc vào loại của đường cong:

  • Curves ECC hơn Thủ tướng Chính Field (thường được gọi là Elliptic Curve và đại diện bởi P-keysize)
  • Curves ECC hơn nhị phân Field (thường được gọi là Koblitz Curve và đại diện của K-keysize)

Với một sức mạnh bảo mật tương đương Elliptic Curve và Kobliz đường cong có kích thước khóa khác nhau, ví dụ như khi chúng ta đọc ECC 571, chúng tôi đang đề cập đến Koblitz đường cong với một sức mạnh tương đương với ECC 521 Thủ đường cong.

Một so sánh về sức mạnh giữa đường cong Elliptic và Kotbliz Curves được báo cáo dưới đây (từ Mikey ECC Dự thảo internet ):

 | Koblitz | ECC | DH / DSA / RSA | 163 | 192 | 1024 | 283 | 256 | 3072 | 409 | 384 | 7680 | 571 | 521 ​​| 15360 

Dưới đây có một so sánh của tất cả các đường cong được lựa chọn bởi tất cả các thực thể khác nhau và tên của mình (từ IETF RFC4492 cho ECC sử dụng cho TLS ):

 Tên đường được lựa chọn bởi các tổ chức tiêu chuẩn khác nhau
 ------------ + --------------- + -------------
 SECG | ANSI X9.62 | NIST
 ------------ + --------------- + -------------
 sect163k1 | | NIST K-163
 sect163r1 | |
 sect163r2 | | NIST B-163
 sect193r1 | |
 sect193r2 | |
 sect233k1 | | NIST K-233
 sect233r1 | | NIST B-233
 sect239k1 | |
 sect283k1 | | NIST K-283
 sect283r1 | | NIST B-283
 sect409k1 | | NIST K-409
 sect409r1 | | NIST B-409
 sect571k1 | | NIST K-571
 sect571r1 | | NIST B-571
 secp160k1 | |
 secp160r1 | |
 secp160r2 | |
 secp192k1 | |
 secp192r1 | prime192v1 | NIST P-192
 secp224k1 | |
 secp224r1 |​​ | NIST P-224
 secp256k1 | |
 secp256r1 | prime256v1 | NIST P-256
 secp384r1 | | NIST P-384
 secp521r1 | | NIST P-521
 ------------ + --------------- + -------------

Có gì ngay lập tức xuất hiện là chỉ có hai đường cong được chọn bởi tất cả các cơ quan chức năng, và rằng có một vị tướng bán phá giá của Koblitz cong do ANSI.The chỉ thường thống nhất giữa các cơ quan chức năng 3 như sau ECC hai đường cong:

  • secp192r1 / prime192v1 / NIST P-192
  • secp256r1 / prime256v1 / NIST P-256

Trong số những lựa chọn của ECC đường cong cho TLS các RFC5430 bỏ qua những đường cong hoàn toàn Koblitz và chọn để chỉ sử dụng:

  • P-256, P-384, P-521

Các ECC Brainpool bỏ qua hoàn toàn những đường cong Koblitz và chọn để sử dụng các đường cong ECC sau:

  • P-160, P-192, P-224, P-256, P-320, P-384, P-512 (đó là chỉ đặc biệt bởi vì nó không phải là P-521 nhưng P-512, chỉ có phím kích thước được gọi bằng ECC brainpool. Tnx Ian Simons từ Athena SCS )

Các dự thảo OpenPGP internet cho ECC sử dụng trong PGP d bè-jivsov-OpenPGP-ecc-06 bỏ qua hoàn toàn những đường cong Koblitz và lựa chọn các đường cong ECC sau

  • P-256, P-384, P-521

Việc mở rộng giao thức Kerberos cho ECC sử dụng quy định tại RFC5349 và được xác định bởi Microsoft để đăng nhập thông minh bỏ qua hoàn toàn những đường cong Koblitz và lựa chọn các đường cong ECC sau:

  • P-256, P-384, P-521

Vì vậy, âm thanh rõ ràng rằng việc lựa chọn bên phải của ECC là P-256, P-384 và P-521 trong khi các đường cong Koblitz đã được bỏ qua cho Top Secret sử dụng và đối với bất kỳ giao thức bảo mật nhạy cảm (IPSec, OpenPGP, ZRTP, Kerberos, SSL / TLS).

Tại sao tôi đã thực hiện phân tích này?

Tôi đã thực hiện phân tích này sau một cuộc thảo luận tôi đã có liên quan đến sản phẩm mã hóa giọng nói nào đó, tất cả đều dựa trên tùy chỉnh và các giao thức độc quyền, mà là tất cả sử dụng Elliptic Curve Diffie Hellman 571 bit / ECDH 571/571-bit ECDH / Koblitz 571 bit.
Tất cả họ đang sử dụng K-571 đó, như được mô tả trước đây, đã được gỡ bỏ từ tất cả các môi trường và các giao thức bảo mật và nhạy cảm là bản thân mình một nhà thiết kế các công cụ mã hóa giọng nói tôi nghĩ rằng sự lựa chọn mật mã của họ là hoàn toàn không phải là sự lựa chọn bảo mật tốt nhất.
Có lẽ nó đã được thực hiện chỉ dành cho mục đích tiếp thị, bởi vì K-571 (Koblitz đường cong) có vẻ mạnh hơn P-521 (đường cong Elliptic dựa trên số Thủ). Nếu bạn có "nhiều hơn một chút" kẻ tiếp thị của bạn có thể yêu cầu để được "an toàn hơn". Koblitz đường cong elliptic là nhanh hơn so với các đường cong elliptic thủ bí mật hàng đầu kích hoạt và do đó cung cấp cho các nhà quản lý sản phẩm một cơ hội để cung cấp "nhiều hơn một chút" trong sản phẩm riêng của nó trong khi vẫn giữ sự trao đổi quan trọng nhanh.

Đó là vấn đề của sự lựa chọn triết học.

Tôi thích theo xu hướng của cộng đồng khoa học với sự khiêm tốn của không xem xét bản thân mình một chuyên gia mật mã, có kiến ​​thức hơn so với an ninh tổng thể và cộng đồng khoa học của chính nó.

Tôi thích thay vì chỉ sử dụng các thuật toán được chấp thuận cho sử dụng trong môi trường có độ nhạy cao (trên phân loại bí mật), đã được lựa chọn bởi tất cả các cơ quan chức năng và các thuật toán mã hóa nhóm phân tích làm việc hiện có ngoài đó và đại diện cho sự lựa chọn của hầu hết các tiêu chuẩn an ninh giao thức (IPSec, OpenPGP, ZRTP, Kerberos, SSL / TLS, vv).
Tôi thích để đếm số lượng của bộ não làm việc trên các mật mã tôi sử dụng, kiểm tra rằng đó là thực sự an toàn, đó là đánh giá liệu có một số điểm yếu.

Số lượng brais làm việc trên Crypto khuếch tán rộng rãi là các thứ tự cường độ nhiều hơn số lượng của bộ não làm việc trên mật được sử dụng bởi chỉ vài người (như Koblitz đường cong).
Vì vậy, tôi không demonizing người sử dụng ECDH 571 sử dụng Koblitz Curve, nhưng chắc chắn tôi có thể khẳng định rằng họ không đưa ra những lựa chọn tốt nhất về an ninh và rằng bất kỳ chuyên gia bảo mật làm một điểm chuẩn an ninh sẽ xem xét thực tế là Elliptic Curve Diffie Hellman 571 bit thực hiện với Koblitz đường cong không khuếch tán rộng rãi, đó là bán phá giá từ các giao thức bảo mật tiêu chuẩn và nó không chứng nhận đầu sử dụng bí mật.

Mobile Security nói chuyện tại hội nghị WHYMCA

Tôi muốn chia sẻ một số slide tôi được sử dụng để nói về bảo mật di động tại hội nghị di động whymca tại Milan.

Đọc ở đây tôi trình bày về an ninh điện thoại di động .

Các slide cung cấp một cái nhìn tổng quan rộng sâu sắc về các vấn đề liên quan đến bảo mật di động, tôi cần phải làm một số slidecast về nó cũng đặt âm thanh. Có lẽ sẽ làm, có thể không, nó phụ thuộc vào thời gian đó luôn luôn là một nguồn lực không đủ.

Mật mã lượng tử bị phá vỡ

Mật mã lượng tử đó là một cái gì đó rất khó khăn, phương pháp mã hóa mà tận dụng pháp luật để bảo đảm thông tin liên lạc phisycs qua đường dây cáp quang.

Để đơn giản hóa hệ thống được dựa trên thực tế rằng nếu ai đó cắt sợi, đặt một vòi nước ở giữa, và khớp với nhau ở phía bên kia của sợi, số tiền của "lỗi" mà sẽ được trên con đường thông tin liên lạc sẽ cao hơn 20%.

Vì vậy, nếu QBER (Quantum Bit Error Rate) đi trên 20% sau đó nó giả định rằng hệ thống đang bị chặn.

Nhà nghiên cứu tại trường đại học của toronto đã có thể lừa hệ thống với một ở lại dưới 20%, 19,7% , do đó tinh chỉnh các ngưỡng được sử dụng bởi hệ thống để xem xét các kênh thông tin liên lạc an toàn vs thỏa hiệp.

Các sản phẩm tìm thấy dễ bị tổn thương được gọi là Cerberis lớp 2 và được sản xuất bởi Thụy Sĩ ID Quantique .

Một số phương pháp tiếp cận possibile để phát hiện các cuộc tấn công đã được cung cấp nhưng có lẽ, IMHO, loại đó của hệ thống không cần phải được coi là 100% đáng tin cậy cho đến khi công nghệ này sẽ có đủ trưởng thành.

Mã hóa truyền thống đã được sử dụng cùng nhau cho đến nhiều năm, cuối cùng đi kèm với mã hóa lượng tử cho dù áp dụng.

Khi chúng ta sẽ thấy một hệ thống mã hóa lượng tử trên một RFC như chúng ta đã thấy cho ZRTP , PGPSSL ?

-naif

Mã hóa không xáo trộn: phải nhận thức được xáo trộn!

Hầu hết chúng ta biết về xáo trộn âm có thể được sử dụng trên hầu hết các loại công nghệ thông tin liên lạc bằng giọng nói dựa.

Cách tiếp cận cực kỳ linh hoạt: các công trình tất cả mọi thứ

Hiệu suất cực: độ trễ rất thấp

nhưng tiếc là ...

Rất yếu: xáo trộn không thể được coi là an toàn.

Chỉ có mã hóa có thể được coi là an toàn theo nguyên tắc của Kerckoff .

Vì vậy, hãy thậm chí không xem xét bất kỳ loại xáo trộn tương tự nếu bạn cần bảo mật thực sự.

Đọc sâu sắc giấy Thực hiện một hệ thống mã hóa giọng nói thời gian thực "bởi Markus Brandau, đặc biệt là đoạn cryptoanalysis.

Giới thiệu về phân tích mã hóa giọng nói SecurStar GmbH Phonecrypt (tiêu chuẩn, sai sót và kết quả khác nhau)

Bài viết này muốn làm rõ và giải thích tốt hơn phát hiện tại infosecurityguard.com regaring đánh giá sản phẩm mã hóa giọng nói.
Bài viết này muốn nói với bạn một điểm khác nhau xem khác với infosecurityguard.com và giải thích đó là hợp lý với Giải thích sâu rộng từ quan điểm bảo mật của xem.
Hôm nay tôi đọc tin tức nói rằng: "PhoneCrypt: dễ bị tổn thương cơ bản tìm thấy ở 12 trong số 15 âm mã hóa sản phẩm và đã đi để đọc trang web infosecurityguard .

Ban đầu nó xuất hiện với tôi như một hoạt động nghiên cứu tuyệt vời, nhưng sau đó tôi bắt đầu đọc sâu sắc về đọc nó.Tôi thấy rằng nó không đúng cách một nghiên cứu bảo mật nhưng có những yếu tố cụ thể đó là một chiến dịch tiếp thị cũng được thực hiện để thu hút các phương tiện truyền thông công cộng và công bố công khai một sản phẩm.
IMHO họ đã có thể lừa dối các nhà báo và người sử dụng vì các chiến dịch tiếp thị được thực hiện hoàn toàn cũng không được phát hiện vào ngày 1 nỗ lực đọc. Cá nhân tôi coi nó như một giá trị vào ngày 1 sẵn sàng (họ lừa tôi ban đầu).

Nhưng nếu bạn đi sâu ... bạn sẽ hiểu rằng:
- Đó là một sáng kiến tiếp thị ngụy trang được sắp xếp bởi SecurStar GmbH và không phải là một nghiên cứu bảo mật độc lập
- Họ xem xét một bối cảnh an ninh duy nhất mà thiết bị địa phương đã bị xâm nhập (không có phần mềm có thể được bảo đảm trong trường hợp đó, như nói rằng SSL có thể bị tổn hại nếu bạn có một Trojan!)
- Họ không xem xét bất kỳ bảo mật cơ bản và tiêu chuẩn an ninh mật mã

Tuy nhiên rất nhiều trang web quan trọng báo cáo nó:

Bài viết này là khá dài, nếu bạn đọc nó, bạn sẽ hiểu rõ hơn về những gì đang xảy ra xung quanh nghiên cứu infosecurityguard.com và kết quả nghiên cứu.

Tôi muốn để cho bạn biết lý do tại sao và làm thế nào (IMHO) họ sai.

Nghiên cứu này đã bỏ lỡ để xem xét an ninh, mật mã và minh bạch!

Vâng, tất cả âm thanh nghiên cứu này giống như đang tập trung vào mục tiêu tiếp thị nói rằng sản phẩm PhoneCrypt của họ là "siêu" sản phẩm tốt nhất của tất cả những người khác.
Bất kỳ chuyên gia bảo mật mà có thể có như là nhiệm vụ của "phần mềm đánh giá" để bảo vệ tính bảo mật của các cuộc gọi điện thoại sẽ đánh giá các đặc điểm khác nhau khác của sản phẩm và công nghệ.

Vâng, đó là sự thật rằng hầu hết các sản phẩm được mô tả bởi SecurStar trong trang web tiếp thị vô danh của họ được gọi là http://infosecurityguard.com có ​​một số điểm yếu.
Nhưng sự yếu kém có liên quan khác và PhoneCrypt không may, giống như hầu hết các sản phẩm được mô tả bị này.
Chúng ta hãy xem lại những đặc điểm cần mật mã cơ bản và yêu cầu bảo mật (thực hành tốt nhất, nền tảng và những điều cơ bản!)

a - an ninh Trough tối tăm không hoạt động

Một nguyên tắc cơ bản trong mật mã cames từ năm 1883 bởi Auguste Kerckhoffs:

Trong một hệ thống mật mã được thiết kế tốt, chỉ có nhu cầu chính là bí mật; không nên có bí mật trong thuật toán.
Mật mã hiện đại đã chấp nhận nguyên tắc này, gọi bất cứ điều gì khác "bảo mật bằng cách tối tăm."
Đọc những gì mà Bruce Schneir, công nhận chuyên gia mật mã và trên thế giới nói về điều này
Bất kỳ chuyên gia bảo mật sẽ cho bạn biết đó là sự thật. Ngay cả một sinh viên đại học mới làm quen sẽ cho bạn biết đó là sự thật. Đơn giản vì đó là cách duy nhất để làm mật mã.
Hầu hết các sản phẩm được mô tả trong tổng quan của SecurStar GmbH, bao gồm PhoneCrypt, không cung cấp chi tiết chính xác về các công nghệ mã hóa của họ.
Chi tiết cụ thể là:
  • Đặc điểm kỹ thuật chi tiết của thuật toán mã hóa (đó là không chỉ nói "chúng tôi sử dụng AES ")
  • Đặc điểm kỹ thuật chi tiết của giao thức mã hóa (đó là không chỉ nói "chúng tôi sử dụng Diffie Hellman ")
  • Đặc điểm kỹ thuật chi tiết về đo lường sức mạnh mã hóa (đó là không chỉ nói rằng "chúng tôi có 10000000 bit kích thước khóa ")

Cung cấp chi tiết chính xác có nghĩa là có tài liệu phong phú với ý nghĩa lý luận và thực tiễn tài liệu bất kỳ cách duy nhất làm thế nào các thuật toán làm việc, làm thế nào giao thức làm việc với các đặc điểm kỹ thuật chính xác để tái tạo nó để thử nghiệm khả năng tương tác.
Nó có nghĩa là cộng đồng khoa học sẽ có thể chơi với công nghệ, kiểm toán nó, hack nó.
Nếu chúng ta không biết gì về hệ thống mã hóa chi tiết, làm thế nào chúng ta có thể biết đó là những điểm yếu và sức mạnh điểm?

Mike Fratto, biên tập viên trang web của mạng máy tính, thực hiện một bài viết tuyệt vời về "Nói KHÔNG với các hệ thống mã hóa độc quyền" .
Đại học Cerias Purdue cho biết điều này .

b - KHÔNG ngang hàng xem xét và KHÔNG Cryptography khoa học chấp nhận không hoạt động

Trong mọi trường hợp và trong bất kỳ điều kiện bạn mật mã, bạn cần phải chắc chắn rằng người khác sẽ kiểm tra, xem xét, phân tích, distruct và reconstract từ đầu công nghệ của bạn và cung cấp những thông tin miễn phí cho công chúng để thảo luận công khai.
Đó chính xác là như thế nào AES được sinh ra và như Viện tiêu chuẩn Hoa Kỳ làm cho mật không (với thi công với đánh giá ngang hàng công, nơi chỉ có chiến thắng được đánh giá tốt nhất).
Một cuộc thảo luận công cộng với một cuộc thi nào mà rất nhiều đánh giá của hầu hết các mật mã nổi tiếng và chuyên gia trên thế giới, tin tặc (với họ, tên và khuôn mặt của họ, không giống như Notrax) cung cấp đóng góp của họ, nói những gì họ nghĩ.
Đó gọi là "đánh giá ngang hàng".

Nếu một công nghệ mã hóa có một đánh giá ngang hàng mở rộng và quan trọng, phân phối trên thế giới đến từ các trường đại học, các công ty an ninh tư nhân, các tổ chức quân sự, tin tặc và tất cả đều đến từ các phần khác nhau của thế giới (từ Mỹ đến châu Âu vào Nga đến Nam Mỹ đến Trung Đông Trung Quốc) và tất cả đều đồng ý rằng một công nghệ cụ thể đó là an toàn ...
Vâng, trong trường hợp đó chúng ta có thể xem xét các công nghệ an toàn bởi vì rất nhiều của các đơn vị có uy tín và quyền lực đến từ rất nhiều nơi khác nhau trên thế giới đã công khai xem xét, phân tích và khẳng định rằng công nghệ đó là an toàn.

Làm thế nào một công ty tư nhân thậm chí có thể nghĩ rằng phát minh vào đó là sở hữu một giao thức truyền thông an toàn khi nó được khoa học nói rằng nó không thể làm điều đó trong một "con đường độc quyền và đóng cửa"?
IBM cho bạn biết rằng đánh giá ngang hàng nó yêu cầu cho mật mã .
Bruce Schneier cho bạn biết rằng "mật mã tốt biết rằng không có gì thay thế cho đánh giá ngang hàng sâu rộng và nhiều năm phân tích."
Philip Zimmermann sẽ nói với bạn hãy cẩn thận của dầu rắn mà câu chuyện là: ". Mỗi kỹ sư phần mềm tưởng tượng mình là một mật mã, điều này đã dẫn đến sự gia tăng của phần mềm mật mã thực sự xấu"

c - mật mã nguồn đóng không hoạt động

Như bạn đã biết bất kỳ loại "nghiêm trọng" và có "danh tiếng tốt" công nghệ mã hóa được thực hiện trong mã nguồn mở.
Thường có nhiều triển khai thực hiện các thuật toán mã hóa tương tự và giao thức mã hóa để có thể xem xét tất cả các cách thức hoạt động và xác nhận khả năng tương tác.
Giả sử dụng một tiêu chuẩn với các chi tiết chính xác và mở rộng về "làm thế nào nó hoạt động", đã được "phản biện chuyên gia" của cộng đồng khoa học NHƯNG đó đã được tái triển khai thực hiện từ đầu bởi một lập trình viên không quá thông minh và thực hiện nó rất nhiều lỗi .

Vâng, nếu việc thực hiện là "mã nguồn mở" này có nghĩa là nó có thể được xem xét, cải tiến, kiểm tra, kiểm toán và người sử dụng cuối cùng sẽ có trong certaintly riêng của nó có một phần của công nghệ "làm việc một cách an toàn".

Phát hành mã nguồn mở mật bộ công cụ Google
Mozilla phát hành mã nguồn mở công cụ mật
Bruce Schneier cho bạn biết rằng mật mã phải có mã nguồn mở .

Một điểm mật mã của xem

Tôi không muốn để thuyết phục bất cứ ai, nhưng chỉ cung cấp những sự kiện liên quan đến khoa học, liên quan đến mật mã và an ninh nhằm giảm thiểu tác động của thông tin sai lệch được thực hiện bởi các công ty an ninh mà chỉ đi là để bán cho bạn một cái gì đó và không làm điều gì đó làm cho thế giới một tốt hơn.

Khi bạn thực hiện an toàn sản phẩm, nếu không được thực hiện sau khi người tiếp cận thích hợp có thể chết.
Đó là một cái gì đó hoàn toàn vô trách nhiệm không sử dụng thực hành tốt nhất để làm công cụ mật.

Tóm lại chúng ta hãy xem xét infosecurityguard.com từ một điểm bảo mật tu tập tốt nhất của xem.

Tên sản phẩm An ninh Trough tối tăm Đánh giá đồng hồ Mã nguồn mở Thỏa hiệp tại địa phương?
Caspertec Tối tăm Không có đánh giá nào Đóng
Cellcrypt Tối tăm
Không có đánh giá nào
Đóng
Cryptophone Minh bạch Công chúng xem xét hạn chế Công cộng
Vàng-Lock Tối tăm
Không có đánh giá nào
Đóng
Illix Tối tăm
Không có đánh giá nào
Đóng
No1.BC Tối tăm Không có đánh giá nào
Đóng
PhoneCrypt Tối tăm
Không có đánh giá nào
Đóng
Rode & Swarz Tối tăm
Không có đánh giá nào
Đóng
An toàn-Voice Tối tăm
Không có đánh giá nào
Đóng
SecuSmart Tối tăm
Không có đánh giá nào
Đóng
SecVoice Tối tăm
Không có đánh giá nào
Đóng
SegureGSM Tối tăm
Không có đánh giá nào
Đóng
SnapCell Tối tăm
Không có đánh giá nào
Đóng
Tripleton Tối tăm
Không có đánh giá nào
Đóng
Zfone Minh bạch Công chúng xem xét
Mở
ZRTP Minh bạch Công chúng xem xét
Mở

* Màu xanh lá cây có nghĩa là nó phù hợp với yêu cầu cơ bản cho một hệ thống an toàn mật mã

* Red / bị hỏng có nghĩa là nó không phù hợp với yêu cầu cơ bản cho một hệ thống an toàn mật mã
Đó là phân tích của tôi bằng cách sử dụng một phương pháp đánh giá dựa trên các thông số mật mã và an ninh không bao gồm bối cảnh địa phương thỏa hiệp mà tôi xem xét vô dụng.

Tuy nhiên, để được rõ ràng, đó là những chỉ số cơ bản được sử dụng khi xem xét một sản phẩm mã hóa giọng nói (để tránh là trong một tình huống xuất hiện như tôi đang thúc đẩy các sản phẩm khác). Vì vậy, nó có thể hoàn toàn có thể là một sản phẩm với mật tốt (minh bạch, phản biện chuyên gia và mã nguồn mở) là một sản phẩm hoàn toàn không an toàn vì lý do nào đó (nặng bằng văn bản, không thể sử dụng làm người dùng không sử dụng nó và sử dụng các cuộc gọi dạng cleartext, bị tổn hại về mặt chính trị, vv , vv).
Tôi nghĩ rằng tôi sẽ chuẩn bị một tiêu chí rộng hơn cho công nghệ mật bằng giọng nói và các sản phẩm mật bằng giọng nói, vì vậy nó sẽ dễ dàng hơn nhiều và nhiều hơn thực tế để có một bộ minh bạch đầy đủ các tiêu chí để đánh giá nó.

Nhưng những người này thật sự là cơ sở an ninh để được xuất hiện trong một hệ thống mã hóa giọng nói tốt!
Đọc một số slide quá khứ hữu ích về giao thức bảo mật được sử dụng trong các hệ thống mã hóa giọng nói (phần 2).

Bây giờ đọc dưới đây một số nghi ngờ thực tế hơn về nghiên cứu của họ.

Khái niệm an ninh của tổng quan là sai lầm: bất kỳ thiết bị tấn công có thể được chặn luôn!

Tôi nghĩ rằng những kẻ hoàn toàn bị mất điểm: bất kỳ loại phần mềm chạy trên Hệ điều hành bị tổn thương có thể bị chặn

Bây giờ họ đang chỉ ra rằng cũng Zfone từ Philip Zimmermann được chia (một phần mềm máy tính), chỉ vì họ cài đặt một Trojan trên máy tính giống như trong điện thoại di động?
Bất kỳ phần mềm bảo mật dựa trên thực tế là hệ thống điều hành cơ bản là bằng cách nào đó đáng tin cậy và bảo vệ sự toàn vẹn của môi trường nơi mà các phần mềm chạy.

  • Nếu bạn có một hệ thống mã hóa đĩa, nhưng nếu máy tính của bạn bị nhiễm bởi một Trojan, máy tính đã bị xâm nhập.
  • Nếu bạn có một hệ thống mã hóa giọng nói, nhưng máy tính của bạn bị nhiễm bởi một Trojan, máy tính đã bị xâm nhập.
  • Nếu bạn có một hệ thống mã hóa giọng nói, nhưng điện thoại di động của bạn bị nhiễm bởi một Trojan, điện thoại di động đã được thỏa hiệp.

Không có vấn đề mà phần mềm bạn đang chạy, trong trường hợp này sự an toàn của môi trường hoạt động của bạn bị tổn thương và bằng cách này hay cách khác tất cả các tính toàn vẹn thông tin và bảo mật bị tổn thương.

Giống như tôi đã giải thích ở trên làm thế nào để ngăn chặn PhoneCrypt.

Những điều duy nhất có thể bảo vệ bạn khỏi mối đe dọa này đang chạy trong một hệ điều hành khép kín với khả năng tin tưởng máy tính, thực hiện nó đúng cách.
Để chắc chắn về bất kỳ "mở cửa" hệ điều hành như vậy chúng tôi Windows, Windows Mobile, Linux, iPhone hoặc Android không có cơ hội để thực sự bảo vệ một phần mềm.
Trên hệ điều hành khó khăn như hệ điều hành Symbian hoặc RimOS có thể chạy các phần mềm có thể được bảo vệ (ít nhất là một phần)

Đó là lý do mà các khái niệm bảo mật mà kẻ đang lợi dụng để thực hiện chiến dịch tiếp thị của họ không có đầu mối.
Đó là chỉ vì họ kiểm soát môi trường, họ biết Flexispy phần mềm và để họ điều chỉnh phần mềm của họ không phải là interceptable khi Flexispy được cài đặt.
If you develop a trojan with the other techniques i described above you will 100% intercept PhoneCrypt.

On that subject also Dustin Tamme l, Security researcher of BreakPoint Systems , pointed on on VoIP Security Alliance mailing lists that the security analysis is based on wrong concepts .

The PhoneCrypt can be intercepted: it's just that they don't wanted to tell you!

PhoneCrypt can be intercepted with “on device spyware”.
Why?
Because Windows Mobile is an unsecure operating environment and PhoneCrypt runs on Windows Mobile.
Windows Mobile does not use Trusted Computing and so any software can do anything.
The platform choice for a secure telephony system is important.
How?
I quickly discussed with some knowledgeable windows mobile hackers about 2 different way to intercept PhoneCrypt with an on-device spyware (given the unsecure Windows Mobile Platform).

a) Inject a malicious DLL into the software and intercept from within the Phonecrypt itself.
In Windows Mobile any software can be subject to DLL code injection.
What an attacker can do is to inject into the PhoneCrypt software (or any software running on the phone), hooking the Audio related functions acting as a “function proxy” between the PhoneCrypt and the real API to record/play audio.
It's a matter of “hooking” only 2 functions, the one that record and the one that play audio.
Read the official Microsoft documentation on how to do DLL injection on Windows Mobile processes. or forum discussing the technique of injecting DLL on windows mobile processes.
That's simple, any programmer will tell you to do so.
They simply decided that's better not to make any notice about this.
b) Create a new audio driver that simply act as a proxy to the real one and intercept PhoneCrypt
In Windows Mobile you can create new Audio Drivers and new Audio Filters.
What an attacker can do is to load a new audio driver that does not do anything else than passing the real audio driver function TO/FROM the realone. In the meantime intercept everything recorded and everything played :-)
Here there is an example on how to do Audio driver for Windows Mobile .
Here a software that implement what i explain here for Windows “Virtual Audio Cable” .
The very same concept apply to Windows Mobile. Check the book “Mobile Malware Attack and Defense” at that link explaining techniques to play with those techniques.
They simply decided that's better not to make any notice to that way of intercepting phone call on PhoneCrypt .
Those are just 2 quick ideas, more can be probably done.

Sounds much like a marketing activity – Not a security research.

I have to tell you. I analyzed the issue very carefully and on most aspects. All this things about the voice encryption analisys sounds to me like a marketing campaign of SecurStar GmbH to sell PhoneCrypt and gain reputation. A well articulated and well prepared campaign to attract the media saying, in an indirect way cheating the media, that PhoneCrypt is the only one secure. You see the press releases of SecurStar and of the “Security researcher Notrax telling that PhoneCrypt is the only secure product” . SecurStar PhoneCrypt is the only product the anonymous hacker “Notrax” consider secure of the “software solutions”.
The only “software version” in competition with:

SnapCell – No one can buy it. A security company that does not even had anymore a webpage. The company does not almost exist anymore.
rohde-schawarz – A company that have in his list price and old outdated hardware secure phone . No one would buy it, it's not good for genera use.

Does it sounds strange that only those other products are considered secure along with PhoneCrypt .

Also… let's check the kind of multimedia content in the different reviews available of Gold-Lock, Cellcrypt and Phonecrypt in order to understand how much the marketing guys pressed to make the PhoneCrypt review the most attractive:

Application Screenshots of application Video with demonstration of interception Network demonstration
PhoneCrypt 5 0 1
CellCrypt 0 2 0
GoldLock 1 2 0

It's clear that PhoneCrypt is reviewed showing more features explicitly shown and major security features product description than the other.

Too much difference between them, should we suspect it's a marketing tips?

But again other strange things analyzing the way it was done…
If it was “an impartial and neutral review” we should see good and bad things on all the products right?

Ok, see the table below regarding the opinion indicated in each paragraph of the different reviews available of Gold-Lock, CellCrypt and Phonecrypt (are the only available) to see if are positive or negative.

Application Number of paragraphs Positive paragraphs Negative paragraphs Neutral paragraphs
PhoneCrypt 9 9 0 0
CellCrypt 12 0 10 2
GoldLock 9 0 8 1

Detailed paragraphs opinion analysis of Phonecrypt
Paragraph of review Opinion expressed
From their website Positive Marketing feedback
Apple iPhone Positive Marketing feedback
Disk Encryption or voice Encryption Positive Marketing feedback
PBX Compatibility? Really Positive Marketing feedback
Cracking <10. Not. Positive Marketing feedback
Good thinking! Positive Marketing feedback
A little network action Positive Marketing feedback
UI Positive Marketing feedback
Good Taste Positive Marketing feedback
Detailed paragraphs opinion analysis of Gold-Lock 3G
Paragraph of review Opinion expressed
From their website Negative Marketing feedback
Licensed by The israeli Ministry of Denfese Negative Marketing feedback
Real Company or Part Time hobby Negative Marketing feedback
16.000 bit authentication Negative Marketing feedback
DH 256 Negative Marketing feedback
Downad & Installation! Neutral Marketing feedback
Cracking it <10 Negative Marketing feedback
Marketing BS101 Negative Marketing feedback
Cool video stuff Negative Marketing feedback
Detailed paragraphs opinion analysis of CellCrypt
Paragraph of review Opinion expressed
From their website Neutral Marketing feedback
A little background about cellcrypt Negative Marketing feedback
Master of Marketing Negative Marketing feedback
Secure Voice calling Negative Marketing feedback
Who's buying their wares Negative Marketing feedback
Downad & Installation! Neutral Marketing feedback
My Demo environment Negative Marketing feedback
Did they forget some code Negative Marketing feedback
Cracking it <5 Negative Marketing feedback
Room Monitoring w/ FlexiSpy Negative Marketing feedback
Cellcrypt unique features.. Negative Marketing feedback
Plain old interception Negative Marketing feedback
The Haters out there Negative Marketing feedback

Now it's clear that from their point of view on PhoneCrypt there is no single bad point while the other are always described in a negative way.
No single good point. Strange?
All those considerations along with the next ones really let me think that's very probably a marketing review and not an independent review.

Other similar marketing attempt from SecurStar

SecurStar GmbH is known to have used in past marketing activity leveraging this kind of “technical speculations”, abusing of partial information and fake unconfirmed hacking stuff to make marketing/media coverage.
Imho a rare mix of unfairness in leveraging the difficult for people to really understand the complexity of security and cryptography.

They already used in past Marketing activities like the one about creating a trojan for Windows Mobile and saying that their software is secure from the trojan that they wrote.
Read about their marketing tricks of 2007

They developed a Trojan (RexSpy) for Windows Mobile, made a demonstration capability of the trojan and later on told that they included “Anti-Trojan” capability to their PhoneCrypt software.They never released informations on that trojan, not even proved that it exists.

The researcher Collin Mulliner told at that time that it sounds like a marketing tips (also because he was not able to get from SecurStar CEO Hafner any information about that trojan):

“This makes you wonder if this is just a marketing thing.”

Now, let's try to make some logical reassignment.
It's part of the way they do marketing, an very unfriendly and unpolite approach with customers, journalist and users trying to provide wrong security concepts for a market advantage. Being sure that who read don't have all the skills to do in depth security evaluation and find the truth behind their marketing trips.

Who is the hacker notrax?

It sounds like a camouflage of a fake identity required to have an “independent hacker” that make an “independent review” that is more strong on reputation building.
Read about his bio:

¾ Human, ¼ Android (Well that would be cool at least.) I am just an enthusiast of pretty much anything that talks binary and if it has a RS232 port even better. During the day I masquerade as an engineer working on some pretty cool projects at times, but mostly I do the fun stuff at night. I have been thinking of starting an official blog for about 4.5 years to share some of the things I come across, can't figure out, or just cross my mind. Due to my day job and my nighttime meddling, I will update this when I can. I hope some find it useful, if you don't, well you don't.

There are no information about this guy on google.
Almost any hacker that get public have articles online, post in mailing archive and/or forum or some result of their activity.
For notrax, nothing is available.

Additionally let's look at the domain…
The domain infosecurityguard.com is privacy protected by domainsbyproxy to prevent understanding who is the owner.
The domain has been created 2 months ago on 01-Dec-09 on godaddy.com registrar.

What's also very interesting to notice that this “unknown hacker with no trace on google about him that appeared on December 2009 on the net” is referred on SecurStar GmbH Press Release as a “An IT security expert”.

Maybe they “know personally” who's this anonymous notrax? :)

Am i following my own conspiracy thinking or maybe there's some reasonable doubt that everything was arrange in that funny way just for a marketing activity?

Social consideration

If you are a security company you job have also a social aspects, you should also work to make the world a better place (sure to make business but “not being evil”). You cannot cheat the skills of the end users in evaluating security making fake misleading information.

You should do awareness on end users, to make them more conscious of security issues, giving them the tools to understand and decide themselves.

Hope you had fun reading this article and you made your own consideration about this.

Fabio Pietrosanti (naif)

ps Those are my personal professional opinion, let's speak about technology and security, not marketing.
pps i am not that smart in web writing, so sorry for how the text is formatted and how the flow of the article is unstructured!

Voice Security and Privacy slides

Below my slides on voice security and privacy from Security Summit 2009 .

mmm, yes i am working in this area from 2005, will write again about it.

sux