342 replies to this topic

[theparasol]

ATM I don't care much about working CI+ solutions since DVB-X providers active in my country don't use mandatory CI+ modules at all.

So I rather do the talking part since coding isn't needed at this moment.

[Lost in Space]

I fully agree that talking is more fun than coding, and yes you are right, only when you suffer you are willing to do something - without suffering I would probably not have done anything myself either. That's exactly the reason why I hinted which crowd might be the most suffering at the moment ... 

 

Technically the same question pops up every few months and the answers here are more or less the same all the time.

 

But as I'm not adding any real value here either ... let's simply sit and wait ...  because the whole thing could gain momentum pretty fast, when some popular solutions would stop working.

 

Have a nice day ...

Edited by gutemine, 19 March 2017 - 19:27.

[zeros]

I got these files from NN2 board. Thanks you for the tip, they are more over my head but I'm going to look at them.

[Lost in Space]

The other thread here were we discussed the solution before points you to the ioctl in descrambler.c

 

The sources will compile and run nicely on every OpenPLI box, and even authenticate the Modules with the evil ceritficates, only the ioctls to set the AES key so that the demux is able to descramble d the AES scrambled output of the CI after decryption with need adjustment because they might differ depending on box and drivers - but as it is all Boradcom what we talk about here the chance is extremely high that the only difference is the ioctl argument - which is easy to find out if you trace a working not open source solution.

 

But I'm repeating myself .... and just looking will not help ...

Edited by gutemine, 20 March 2017 - 20:00.

[littlesat]

   it+made+me+happy+high+five+_3428009e229944c396690d6d27d76ce2.jpg   23.86KB   24 downloads

Edited by littlesat, 20 March 2017 - 20:00.

[athoik]

VU+ ioctl

ioctl(3, 0xa, 0xbeb067b4)               = 0

[Lost in Space]

0xa would be 10, dreamboxes use 137 - change the code and try it out ...

 

#define CA_SET_DESCR_DATA ... is at the beginning of descrambler.c

Edited by gutemine, 20 March 2017 - 21:20.

[Yuri666]

Why your walk around ioctl every time?

Just read ci+ specification part 5.6.2.3.4, include openssl/aes.h and use function AES_decrypt()

Without any ioctl 

[Yuri666]

Good old exampe: https://kahdev.wordp...he-openssl-api/

[littlesat]

0xa would be 10, dreamboxes use 137 - change the code and try it out ...

ioctl(3, 0xa, 0xbeb067b4) = 0

 

This simply means you never can 'design' a real common solution....

Edited by littlesat, 22 March 2017 - 13:25.

[Lost in Space]

The CI output screen is always AES encrypted (well some modules I think you can switch to old DES), which means using Software decrypt for AES will just keep your CPU pretty busy and is useless, as all up-to-date broadcom SOC can do the job nicely. On a PC of course the story is different ....

 

And if I count the box specific case statemens and if then/else in the OpenPLI git (despite your BSP layer) I will end up in the dozends - hence I'm not willing to follow your argument with 'real' common solution either.

Edited by gutemine, 22 March 2017 - 17:52.

[Yuri666]

using Software decrypt for AES will just keep your CPU pretty busy and is useless, as all up-to-date broadcom SOC can do the job nicely. On a PC of course the story is different ....

For my view software aes decrypt get less resources when csa decrypt. At orange pi pc with 2 core arm processor aes decrypt get about 5-10% cpu time. Just for information... 

[Lost in Space]

This is nothing new, but they are not designed to do the job in hardware ... so you have no other choice - the SOC of a STB are designed for this kind of work.

 

But anyway, nobody will stop anybody to invent a better mousetrap

 

Pesonally I would recommend to have a working solution BEFORE thinking about (better ?) alternatives ....

Edited by gutemine, 22 March 2017 - 19:30.

[Yuri666]

No, i'm not thinking about alternatives, i'm recommend a working solutions... 

[MastaG]

A bit offtopic here, but is AES acceleration supported by most broadcom SoC's?

It would be nice to have OpenSSL taking advantage of this, if possible.

That would benefit a lot of things.. playback of AES ecnrypted hls streams using ffmpeg, OpenVPN etc..

[athoik]

All receivers have some kind of HW acceleration, all of them implement the DVB CSA, some also DES and newer ones include AES.

None of them uses CryptoAPI to expose internal accelerators to userspace, so that OpenSSL could use it.

The Google has an open source implementation of HW acceleration on mips (not receivers, but network devices)

https://wiki.openwrt...roadcom.bcm63xx
https://code.google....-gflt100/source
https://github.com/j...har/spudd/impl2

Would be nice drivers to expose /dev/crypto node, we are moving in https everywhere, so having acceleration won't harm, right?

@Yuri666, is there any software in Linux (not receiver related, but pure Linux with DVB API) that implements a softciplus?

Edited by athoik, 22 March 2017 - 21:44.

[Yuri666]

is there any software in Linux (not receiver related, but pure Linux with DVB API) that implements a softciplus?

I didn't named it "softciplus" It just ciplus implementation worked with ci+ CAM and based on dream ciplus souces and software aes decrypting by openssl lib. And yes, it's version of very popular linux dvb soft. 

[samsamsam]

@athoik

@MastaG

 

I only want to tell you that OpenPLI with gstreamer use gio-networking to provide https support.

The default TLS backend for gio-networking is based on gnutls library.

 

The gnutls  is much, much slower than OpenSSL. So, maybe the first step will be to change change default gnutls backend to openssl backend for gio-networking?

[athoik]

@samsamsam,

It seems in OpenPLi 5 it is ready.

/opt/openpli/openpli5$ find openembedded-core/ meta-openembedded/ -type f | xargs egrep -i "gnutls|openssl"  | grep -i gstre
openembedded-core/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc:PACKAGECONFIG[dtls]            = "--enable-dtls,--disable-dtls,openssl"
openembedded-core/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc:# ensure OpenSSL is used for HLS AES description instead of nettle
openembedded-core/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc:# (OpenSSL is a shared dependency with dtls)
openembedded-core/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc:PACKAGECONFIG[hls]             = "--enable-hls --with-hls-crypto=openssl,--disable-hls,openssl"

@Yuri666, good that finaly linux users will be able to use CI+ cams, is it a private or public code yet?

[Yuri666]

Until now it private. But all changes...